I created a chrome extension and I released an update few days ago. As far as I know, when the user re-opening the browser or restarting his pc, chrome should auto update the extensions automatically. However, I noticed that for some of my users, even when they restarted their pc, they still on an old version of the extension and it won't auto update.
The current newest version is 1.3.2. I uploaded it few days ago. Some of the users are still on version 1.3.1 even though they restarted their pc.
Why does it happen? As far as I know there is no option to disable auto-update of extensions..
UPDATE:
Chromium bug reported (Edit suggestions are welcomed): https://code.google.com/p/chromium/issues/detail?id=537646&thanks=537646&ts=1443630404
You don't explicitly say this anywhere, so I'm going to assume your extension doesn't check for updates? I've never had this issue personally but I also have my extensions listen for updates at runtime using chrome.runtime.onUpdateAvailable and request a check using chrome.runtime.requestUpdateCheck. This should solve your auto-update issue. Also, here's a great answer to a similar problem: How to cause a chrome app to update as soon as possible?
Related
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
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.
My project is built in .net v4.0. Since a Chrome browser update last week, every page triggers a "Page(s) unresponsive" alert. The alert occurs on every page regardless of whether or not the page uses ajax. This can't have just affected my project! Has anyone any advice on how to resolve this issue. ALl other browsers are fine.
The only way round this I believe is to ask clients to install the beta version of Chrome (which includes a fix for this bug). To do this they should select to instal the Beta channel for Windows (or Mac) from here http://dev.chromium.org/getting-involved/dev-channel.
My application runs fine again using the beta version.
I suspect the next chrome version will be released soon anyway as this bug is causing widespread problems.
Let me preface this question by saying: It's crazy. I know it is. But the requirement is not mine, it's someone else's, and I'm trying to honor it.
I need to install a months-out-of-date version of Google Chrome so I can run repeated tests against it. But it's proving to be surprisingly difficult to turn Chrome updates off.
I did the trick of disabling the "Google Update" plugin in chrome://plugins. After that, I uninstalled Chrome and installed the old version. I double-checked that the version was the old version and that updating was non-functional ("error 3"). I didn't even see "Google Update" listed in chrome://plugins at all after this. So I thought I was good.
Then just now, I fired up Chrome to look at it again, and it was back to the newest version!
Is there something I overlooked? Are they doing some kind of black magic here?
Windows
For Microsoft Windows, here is the simplest and lowest-impact solution I have found.
Create a text file with these lines:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update]
"AutoUpdateCheckPeriodMinutes"=dword:00000000
"UpdateDefault"=dword:00000000
Save it to a file ending with ".reg" somewhere on your desktop. Double-click it to install new registry keys.
This disables automatic updates, and when you open "About Google Chrome" from the tool menu, you get the helpful message "Updates are disabled by the administrator."
Mac
(Instructions anyone may want to add for Mac OS can go here...)
Don't do this.
Really. I wasn't kidding. Updates are important.
See #1.
You're still here, so I can only assume that you're crazy enough to really want to turn off updates: http://support.google.com/installer/bin/answer.py?hl=en&answer=146164 explains how you can disable updates via policy. Editing registry entries locally should be effective.
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.