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
Related
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.
Background
I've been using the crx-hotreload package to auto-reload my chrome extensions during development because it's annoying to have to click the refresh button on the Extensions page every time you make a change; however, this package doesn't work with MV3 because it uses the chrome.runtime.getPackageDirectoryEntry method, which seems to have been removed from chrome.runtime in MV3. I can't find documentation to confirm that it was removed, but it's not there when I try to use it.
Questions
Does anyone know how to get access to all the files in the extension directory in Chrome Extension Manifest Version 3?
Or generally, is there a better way that I can hot-reload my chrome extensions during development that would work for MV3?
This is one of many things based on DOM capabilities of background pages that are removed from ManifestV3 because service workers don't have DOM. For example, getPackageDirectoryEntry is using the old nonstandard FileSystem API in its returned value.
As to why, apparently the switch to service workers simplifies the internal source code in Chromium, even if it doesn't provide any real improvements for extension authors or users.
At this point all you can do is present a convincing use case and ask Chromium developers via https://crbug.com to implement an alternative API.
This is the context: Suppose there is a plug-in, P, available at the Mozilla Firefox add-on site.
Consider a malicious user that modifies P, for example, to make it deviate from the normal behavior. My first question is:
Could the Firefox browser detect that the plug-in is not the original one (i.e., the one that was downloaded from Firefox site? If this can be detected, could the Firefox browser disable the (modified) plug-in?
Now consider the case of a Web site that interacts with the plug-in P. For example, the site allows access to the web content only if the plug-in is original (it has not been modified).
My second question is:
Could the site be able to detect that this malicious user modified the plug-in?
Firefox detecting changes
All extensions which are downloaded from AMO are cryptographically signed by Mozilla (link 2). If the extension is modified in any way, Firefox will automatically detect that there have been changes and will disable the add-on.
However, if the user is running Firefox Developer Edition, Firefox Nightly, Unbranded Beta, or Unbranded Release, they can change a preference such that the modified extension will not be disabled. The modification will still be detected, and the user informed in about:addons (Ctrl-Shif-A, Cmd-Shif-A on OSX). It is also possible for the user to download the source code for Firefox and compile their own version which disables add-on signature checking.
Temporary add-ons
The normal release and beta versions of Firefox do not permit the user the option to permanently install and run extensions which have not been signed, or where the extension has been changed after signing. However, they do, along with all other versions, permit an extension to be loaded as a temporary add-on even if unsigned, or changed. This makes it impossible unsigned add-ons which require a browser restart in those versions of Firefox.
Summary
Mozilla singing add-ons is intended to prevent add-ons, which are malicious, or that just have not been reviewed by Mozilla, from being downloaded and installed by naive users. Thus, to install an unsigned, or changed, add-on, the user has to jump through extra, inconvenient steps (not use a branded release or beta Firefox, or use a temporary add-on install). However, signing does not, and was not intended to, prevent the user from intentionally changing an add-on and not being able to run it.
Website detecting that the extension has changed
No, assuming that the modifications to the extension are intentionally being hidden, there is no guaranteed way for the web page to detect that a change has occurred. The modified extension can spoof any information that is provided to the web page by the original extension code. You can make this hard to do, but it can not be guaranteed.
You have not mentioned why you are wanting your website to be able to detect these changes. Thus, without guessing as to the purpose, it is not possible to provide you with reasonable alternatives.
You're asking for DRM, i.e. the ability to verify that a remote piece of software running on general purpose computing hardware is executing the code which it itself claims to be executing.
This is not possible, since the claimant can always lie and run any code snippet used for interactive authentication in some form of emulator.
Depending on what you're actually trying to achieve you should use user-specific authentication, i.e. tie site access to some token or password instead of the addon, or treat all inputs by the addon as unstrusted and verify them against whatever protocol they should follow.
In short: Validate data, not code.
I want to add a button to my visual C++ form that will open with a specific browser. So far for links I've been using:
System::Diagnostics::Process::Start("UrlHere")
Which, as standard, opens with whatever your default browser is.
I'm wondering what the process would be to force the URL to open with a specific browser and if it's possible without the use of ShellExecute?
Edit - You are correct, this is C++/CLI. Removed the C++ Tag.
Edit Edit - Apologies if it came across as misleading. Some slight elaboration;
The buttons will launch to application URL's, some of which can only be used in Internet Explorer, others that CAN (and should) be used in Chrome. This is why I need to avoid using the default browser and have different buttons using different browsers when launching URLs
Before answering the 'how', I'd like to ask the question "should you be implementing this?"
By not launching the user's default browser, you are subverting the user's decision.
Perhaps the user prefers a particular interface, and is willing to live with the incorrect renderings that come with it.
Perhaps the user has a browser addon that they really need, such as a screen reader for the blind.
You are requiring additional software installed that the user may or may not want.
Perhaps the user doesn't want Chrome. Perhaps the user prefers FireFox.
You are saying that you know which browser is best, now and forever.
What if the next version of IE makes it work with the sites that are currently Chrome-only? What if the next version of Chrome fixes the sites that are currently IE-only?
What if the site changes so that it works in more browsers?
Do you go back and release a new version of your software that changes the browser for particular sites?
You're trying to solve a problem that may already be fixed.
Both Chrome and Firefox support a addon that will render a tab using the IE engine. It can be set to automatically activate when certain URLs are seen.
Perhaps there is a browser that already works with all your sites, that you don't know about.
Therefore, my recommendation is no, do not do this. The user has decided which browser they want to use, respect that decision and use the default browser.
That said, here's how you would do it: You could use the CreateProcess method, but you're in managed-land, so you might as well use it. Use the Process class to launch the new process for you.
Process^ browserProcess = gcnew Process();
browserProcess->StartInfo->UseShellExecute = false;
browserProcess->StartInfo->FileName = "C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe";
browserProcess->StartInfo->Arguments = "http://www.google.com";
browserProcess->Start();
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.