VSTS - Work (Backlog Board) - Not Saving - google-chrome

Good Afternoon All,
When my colleague is using VSTS on Google Chrome the board seems to constantly be saving.
This is on Work - Backlog - Board.
He is dragging one of the records to another place on the board.
When he does this it just says saving...... for ages.
On my computer it does this perfectly fine but on his it does not work.
Is there any settings that has been applied to his account that could cause this or is this down to just a browser issue.
Any help would be grateful!

It seems a browser issue, not VSTS issue. You could ask your colleague try on other browsers, and n Chrome, you could try the following items:
Check whether the Chrome is the latest version.
Clear browsing data.
Use a incognito window.
If none of above works, try to uninstall the Chrome and reinstall it.

Related

How to troubleshoot a history.go(-1) failure on one machine and only in Chrome

history.go(-1) has no effect in iFrame from different domain, but works in chrome on another machine.
Given a start page with an iFrame from a different domain.
And a FirstIFramedPage.html with a link to SecondIFramedPage in the different domain.
When I click on a back button with onClick="window.history.go(-1)" it has no effect.
However, it does have the desired affect (to navigate the frame back to FirstIFramedPage.html) in every other browser I've tested AND on another machine with the same version of Chrome.
chrome: Version 66.0.3359.181 (Official Build) (64-bit)
I have a fully working example here: https://github.com/jimlesch/ChromeIFrameHistoryFail
the readme.txt has instructions on how to reproduce this issue.
What I've tried:
running in incognito mode.
disabling extensions.
using an iframe from the same domain (works as expected, but not possible in my scenario)
Uninstalling and reinstalling Chrome.
Installing Chrome Beta to see if it behaved differently (still fails for me on 5)
Looking at chrome://tracing (could not make heads or tails of it)
I am looking for help on how to further isolate this issue, since I cannot reproduce it on another windows 10 machine with the same version of chrome. Thanks for any help you could provide.
It would appear this is a chrome bug introduced in field trials of "Site isolation". These field trials get applied to 10% of the stable build (and 90% in beta builds).
I was able to revert to expected behavior by choosing to "opt out" in "Site isolation trial opt-out". This setting is available under: chrome://flags/#enable-site-per-process.
Also see this duplicate bug for a richer discussion: bugs.chromium.org/p/chromium/issues/detail?id=845923

Dev Tools Crashing on Chrome Version 50.0.2661.102 m

So i have the following problem.
Any time i click on a request to view the headers/payload/response
i receive a not responding window.
If i wait ~2 minutes it works.
So what i receive here is a developer tools not responsive status when working on local machine.
I tried to re-install chrome. Nothing changed.
Current Version is: Version 50.0.2661.102 m listed as up to date.
Is there any possibility to get some logs or did anyone faced the same problem?
I think it can be relevant if i show what extensions i have installed.
But i tried to enable/disable them and nothing changed.
And i get the same comportment in incognito mode too.
Later edit: I somehow identified the problem. Idea is that chrome is trying to display the cookie (request headers) which was 18k characters long and it looks like this is slowing a lot developer tools and sometimes make him crash.
I just saw that in Mozilla cookies are limited to a couple of characters (display perspective) and after that they show ...
I can't find any known issues regarding this crash, so here are a couple of steps you could take:
Use the Chrome Cleanup Tool and see if that helps.
Fully clean and re-install Chrome (including deleting user folders). If it works after that, you can slowly add extensions and plugins back and see if any reintroduce the problem.

google chrome ver. 45.0.2454.85 do not work with comodo guard32.dll ver. 8.2.0.4674

On windows 7x32 with comodo internet security 8.2.0.4674 (that uses guard32.dll in %systemroot%\system32 directory) I updated google chrome to version 45.0.2454.85, but could not run it, because got error in module guard32.dll.
I was able to solve this problem only renamed guard32.dll, after that chrome runs.
I think it is bad way, especially if I will update CIS, it will place guard32.dll again and chrome do not run again.
How to solve this problem?
As a workaround, go to the settings of Comodo > HIPS > shellcode injections and add chrome to the exception list. That should make chrome and comodo work together again, letting you upgrade both. However, note that the chrome process is not protected from shellcode injection anymore, of course. Both the chromium team and Comodo know of the issue. Once fixed you should be able to remove exclusion again.
https://code.google.com/p/chromium/issues/detail?id=527496
https://forums.comodo.com/bug-reports-cis/guard32dll-kills-chrome-45-t112785.0.html
HIPS setting is the ticket (for now I guess)
A lot of scary sounding links for fixes for this focused around viruses. Spent a few hours on those (no hits), but after this link ...tada, hips and back and running. THANKS! ...phew...
That didn't work for me. I used to use ZoneAlarm and had to ditch it, because it started stomping on my other legit programs like this. If Comodo doesn't issue an immediate fix, I will have to uninstall it, as well, and use something else.
Disabling HIPS, adding exceptions, etc. does not work. Goggle Chrome will not run. I guess I have to uninstall Comodo and use something else. I have already spent half a day on this crap.
Adding to the exclusion list did work however to get chrome to run I must right click the exe or shortcut of the exe and select "Run in COMODO sandbox". Simply clicking the icon will not run chrome anymore.
Find in the COMODO Firewall HIPS section 'detect shell code injection' and follow Brave Cobra's instructions.

Chrome 22 Developer Tools - Global Sources Search not working right (ctrl-shift-f)

this morning I noticed my Chrome updated to Chrome 22 and that the search in the top right has been removed and can now be accessed with ctrl-f.
I also noticed that ctrl-shift-f is no longer working as expected... (but this is inconsistent)
The global search has been a huge time saver for me, and now sometimes it doesn't work until I've viewed a script at least once.
For example, I have 5 scripts that I know all contain "fn_init"
I search for fn_init and nothing comes up.
I open one of those scripts and then ctrl-shift-f again, and finally get a matching result for just the one file...
Is this working as intended? Am I missing an option or something? My dev tools config options are:
General
Disabled cached
Sources
Show folders checked
Search in content scripts checked
Also: how can I install an older version of Chrome and stop it from updating automatically?
To get an older version of Chrome your best bet is to find a build of Chromium from https://chromium-build.appspot.com/p/chromium/console however if this if for devtools stability you are missing out on a lot of new features and bug fixes.
As for Search across all files it is still there and CTRL-SHIFT-F on Windows and CMD-OPT-F on Mac. See Addy Osmani's post https://plus.google.com/115133653231679625609/posts/e4W2kdrFJY9
If you find issues as bugs, it is better to raise the issue on http://crbug.com/new as it will get direct attention from the engineering team there.

Quirky Google Chrome Beta/Dev channel behavior persists even after uninstalling and reverting to stable

We have several FogBugz customers who have reported an error in Chrome where if the user presses Enter in an edit box, the edit box will lose focus and they'll have to click back in to the box for it to gain focus.
All users reporting this error (that we're aware of) have mentioned using Chrome Beta. We don't support Chrome Beta, so we advise downgrading to Chrome Stable. We can't repro the bug on Stable.
One of our users uninstalled Beta and installed Stable. He tried again and was again able to reproduce the bug, even after clearing his browser's cache (with no tabs open) on Stable.
In a related scenario, another member of our team noticed quirky behavior in Chrome persisting when switching from Chrome Dev to Chrome Stable. He also cleared his cache and noticed the behavior persisting in Chrome.
Have any other web developers experienced this kind of behavior in Chrome with customers using their web applications? If so, is there anything you can do within your application to help users and/or do you know of a way to completely "wipe" Chrome and revert it to the Stable version? (at the moment, the latter option is preferred).
Moving up versions should be okay, since Chrome is designed to upgrade smoothly.
Moving down versions (like dev to stable) can be problematic, since there's really no provision for older versions of Chrome to understand new versions of the user directory.
If you want a fresh start, you can wipe your entire user data directory. However, since this directory contains everything about the user (caches, saved passwords, apps/extensions, etc), all of that will be lost.