I'm building a Chrome Extension and we published the first version of it recently. We already have a group of users who installed it.
We are now trying to push an update (with bug fixes and new features), but are getting mixed messages from Chrome documentation as it pertains to the user experience for updates. They've mentioned that by default, the updated version will be pushed to the Chrome Web Store, but existing users need to restart their browser for the update to be pushed or manually do to chrome://extensions.
Is there a way to automatically push an update to a user that has already installed our Chrome Extension (without any action required by users)?
We expected the new version to be automatically updated for the existing users. However, when the new version was published, the existing users would still be on the previously version 2-3 days after (without restarting their browser)
We expected the users to automatically access the new version without any action to the browser or extension dashboard.
Normally the browser autonomously checks if there are updates every few hours. If I remember correctly every 4 hours.
Therefore it is unlikely that the browser will not receive the update if the browser has been open for several days.
However, if the extension is MV2, if there is a persistent background script and if at least one extension page is currently open in the browser then the update may be stucked until that page\tab is closed.
Once the latter is closed, the extension should receive and install the update at the next browser check.
If your extension falls into this case then you could define a handler for the runtime.onUpdateAvailable event where you force the reload of the extension.
"Is there a way to automatically push an update to a user that has already installed our Chrome Extension (without any action required by users)?"
If by "a user" you mean "some users but not all",
then you could think of a system that sends a push message from your backend and manage its reception from a service worker which will run the runtime.requestUpdateCheck method only for the desired user(s).
However, this will imply the implementation of a sort of user registration\authentication in order to recognize it at the moment of the forced update request.
Note that you will not be able to selectively allow some users to upgrade while excluding all others. Basically, with this technique you would speed up the update only for one or a part of your users, so this method (not exactly easy to implement) could be overly redundant.
Related
I am making an extension that should include in its background script some variable that should be unique for every user and that must not be altered. I was able to soolve this in Firefox since it is possible to generate the extension package inline and install it with not problems.
As far as chrome is concerned, I cannot rely on cookies, session or localstorage since the can be erased if the user deletes his browsing history.
Then my question is very simple, is it possible to pass the variable when installing the extension from chrome webstore using a link lik this for example :
https://chrome.google.com/webstore/detail/search-by-image-by-google/dajedkncpodkggklbegccjpmnglmnflm?id=somevar
YOu may use Sync Storage in Chrome: https://developer.chrome.com/extensions/storage
It use Google Drive in background to store data. Even if the user clear browser data it will remain intact.
The user will not see this data on Drive because they are not visible in the drive's UI (files are hidden) so probably he will not be able to delete it.
However you must consider a situation when the user is not logged in to Chrome or the user disabled sync options. In this scenario storage.sync will behave like storage.local.
Even when the user clear browsing data, the data stored in storage.local will remain. They will be deleted only on uninstall.
Edit:
Data are stored on Google Drive using syncFileSystem API - not storage.sync. However it doesn't change the solution I wrote.
I need to edit and then publish my Chrome extension. I know that it sometimes takes over an hour to publish an extension, but once it has been published, can I assume that all users are using this new extension version? Or might they still be using the old one for a while? And, if so, for how long?
I publish via the Chrome dashboard. Sorry if this is the wrong place to ask. I have tried searching through Chrome's documentation.
Issue: I need to update my server side code, but if a user is still using the old extension version, then it will fail very badly.
You should not make any assumptions about the extension update frequency. The update frequency is 5 hours by default. This value can be changed by the user through the --extensions-update-frequency flag. In practice, most users will stick to the defaults though. And do not forget that it is unreasonable to expect that all of your users have their computer online all the time.
You should keep the code for the old and new version at the server's side. If you haven't done before, include a version identifier in your request. This version identifier does not need to map 1:1 to your Chrome extension version; just use a value and keep incrementing it for every significant API update.
If you did not include a version identifier in your previous version, just assume that the user is using the old version if the version identifier is missing from the request, and consistently include the version identifier in requests from your new Chrome extension.
If you have set a minimum_chrome_version in your manifest file, then the user will also be stuck at an old version of your extension if they use an older Chrome version.
Though not relevant for your specific situation, extension authors can choose to distribute their extension to a specific percentage of users via the dashboard at the Chrome Web store. When this feature is used, you obviously have users who are still using the old version.
You have to handle in your code the possibility of users having the old version. Its not published how long that might be but from experience it can be a full day at least.
According to the docs and other sources the update happens within a few hours from publishing.
Every few hours, the browser checks whether any installed extensions or apps...
The default update check frequency is several hours,
I suggest you implement a mechanism to check the version of the extension making the request and if it is not current, either fallback to differently handling the request (based on the old server-side code), or inform the user they have to update (although I would not advice that, as it might scare and annoy users).
In order to force an update of one's extension:
but you can force an update using the Extensions page's Update extensions now button.
Basically, you have to go to the Extensions page, check "Developer mode" and press the "Update extensions" button that appears.
Bottom line
I would:
Implement a mechanism to include the version in a request
Maintain two code based on the server (for a few days only)
serve each request based on the version
I would like to display the latest top 3-5 entries of my extension change log (TXT file) when it's auto-updated and ideally in a balloon-type event like the one when you have successfully installed an extension. It should show/popup near the wrench-icon area. Like a replacement for #history that GM scripts have.
There are already a few SO questions about how to get extension version like here.
There are also one here to detect if it's an install or update based on version.
It is not desktop notifications I want.
My question is how to make the balloon and populate it with the lines.
An alternative is open my options.html page in a new tab and show the change log entries there somehow. Requires tabs permission in the manifest.json file.
chrome.tabs.create({url:chrome.extension.getURL('options.html')});
Any ideas how to do this?
Or is this impossible to do?
There's neither a mechanism to create a "balloon" notification (that's reserved for native Chrome code), nor to pop out the popup without user interaction. Your automatic notification methods are fairly limited: creating a new tab with a changelog is certainly possible, but not particularly user-friendly (since it will simply open at some arbitrary time, completely remote from the user's intent).
If possible, I'd suggest waiting to notify the user until she interacts in some way with the extension. Clicking on a page-action, for instance, could have some sort of infobar-like note at the top of the popup's UI inviting the user to read more about the update.
So I have a Chrome extension which uses Google Analytics for tracking various things. One of those things is the extension version, set using a custom variable every time the background page is started. Now my question is: Which scope should I use, visitor or session level? I can't figure it out based on Google's documentation, and no one else seems to have had this issue. I'm not even sure there's any difference, or maybe it's just something like "it's bad practice to overwrite visitor level variables".
Chrome extensions are have some very specific characteristics and the answer to this question is not applicable to anything that is not a Chrome extension.
From your question I believe you do some basic tracking on your background page, but I assume you also do so on a popup or you fire an event if the user do some action with your extension.
In that case I'll strongly suggest that you use a Visitor Level Custom var.
The problem is that the background page is loaded only once, when the browser opens up, and it's like a tab that stays open and silent, possibly hosting some callback functions for events that may or may not happen.
Because of that once the visitor first loads your extension you'll see a pageview from you background page setting this custom var.
After that there may be a silent period where your extension doesn't track anything, this period can take hours, until hopefully the user interacts with your extensions and tracks additional data to analytics. When it finally happens chances are that over half an hour has passed since the backgroun page loaded. If that is true the visit (or session) that was started by the background page is already over. A visit with no activity for 30 min is closed by analytics. In that case that interaction will spawn a new visit.
If you set the Custom Var as a visit leve variable chances are that when you see interactions on the extension, these interactions won't have the custom var.
This approach has the bad side effect that if the version of your extension changes and the user doesn't reload the browser the version is not going to be updated, and it will be erroneously registered as te old version.
That's very unlikely. And the only way to fix it is to check the version of your app everytime the user does an interaction and set that custom var again. I believe that this is excessive and I don't do it in my extension. Still if you opt for it, it really doesn't matter if it's a visit level or visitor level custom var.
I built a quick one-off chrome extension about a month ago during the SOPA craziness. Long story short, it unblacked Wikipedia, so that people who needed it could get some work done.
Once the blackout was over, I updated the app to no longer have any effects on any websites. I also modified it so it would put a console.log() saying essentially "The blackout is over. SOPA is still important, but you should uninstall this extension".
Unfortunately, a month later, I'm still showing that 90% of the original users have the extension installed. Certainly it doesn't have that large of a footprint, but as a developer I feel it's my duty to not let my extension become crapware on my user's computers.
Is there a way to forcefully uninstall a chrome extension? Is there some way that would be unintrusive to the user that I could inform them that they should uninstall the extension?
You can update the extension so that it requires the 'management' permission, and then use chrome.management.uninstall to make the extension uninstall itself.
In my opinion, there is no way in this situation. Unless
If your extension makes a request to a server that you can access, such as a web service from you, maybe you can send an alert to your users.
If auto update is enabled in your extension, you can update your extension. In your updated version, you can show users an alert (shouldn't be a real javascript alert. Some kind of alert) to uninstall your extension.
If auto update is enabled, you may update your extension to do nothing. Just a console.log message.