I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.
Related
Looking for the best way to lock chrome browser tweaking per user on shared lab computers so each user gets a consistent experience on login. Currently some users will pollute the chrome experience requiring the IT team to do some housekeeping. I would like to remove all user changes if possible, so each experience is fresh clean browser.
Tried: GPO in place to block the settings url changes and clear history on exit but customize is still available. Reached out with no luck, seems like support is firewalled at google and out of reach.
I've written a simple web app to factory-reset bluetooth devices that were accidentally turned on during shipping. The app scans for a class of bluetooth devices (those made by the company I work for), renders a list of devices found, and, when I click a button next to a device in the list, sends a reset message to the device.
This is a very manual process and I'd like to automate it. The problem is the Chrome dialog that asks for permissions to pair with a device. I am trying automate the app with Puppeteer, but I can't find a way to either (a) programmatically grant permissions to pair with a device or (b) to select the device in the dialog and click the "pair" button via Puppeteer. Anyone know if what I'm trying to do is possible, or if there's a better way to achieve the goal? Thanks!
This is not possible in Chrome. (I work on chrome.) The automation that does exist for Chrome's testing is layered such that actual Bluetooth connections aren't made.
Eventually we would like to enable this workflow via Enterprise configuration controls. But that is not started yet and there is no date commitment.
One alternative is to use node.js, though you lose the easy interface. You might build the reset backend in a node server and have it serve a web page interface.
I'm resurrecting an old project of mine as a way to learn some new stuff.
I'm doing this code lab from IO Add Your Web App to a User's Home Screen.
Is there any way, other than connecting a phone and waiting a lot, to test if users will be shown the prompt below?
I've tested it with Lighthouse and all tests come back green, but I've never seen the prompt. It feels very random at the moment.
The answer to This question puts the stuggle into perspective:
The user has visited your site twice over two separate days during the course of two weeks
Does that mean I need to wait 2 days between changes to see if it worked?
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Increasing Engagement with Web App Install Banners
anshulix has correctly answered the question, but I thought I'd put in a more verbose answer.
To remove the waiting and other requirements for the save to homescreen prompt, then you need to enable a flag.
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Which comes from Increasing Engagement with Web App Install Banners
It's important to remember that you are setting this flag on the mobile browser, not on your desktop browser. For some reason this didn't occur to be for a while!
You also need to restart mobile Chrome for the flag to take effect. If you've got your tabs mixed in with your other apps, this can be tricky because you need to hunt down all the tabs and close them. (Or find a better way to close Chrome.)
I found it much easier to do this debugging in Chrome Dev, rather than regular chrome because a) I know it's got the latest fixes in it, and b) because I only have 1 tab open, so it's easy to restart the browser.
If you are doing remote inspection, there is an issue about the messages that come up in the console. In Chrome 50 you get:
App banner not shown: could not determine the best icon to use
This doesn't seem to be true; in more recent builds—e.g. mobile Chrome 52—save to desktop works just fine. It's a disconcerting but useless error.
As a bonus helpful thing, realfavicongenerator does an excellent job of generating all the icons and the manifest file that you need.
Could anyone explain how Chrome Extension upgrading works?
Let's say I publish version 0.0.1. After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2? If not, what is the process to sending/updating Chrome Extensions?
Thanks!
After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2?
Yes. By default, if you publish (not just submit a draft, actually publish and wait for the automated review process to complete) a new version then all users will get it.
..eventually.
Chrome does not get push notifications about extension updates; it instead polls the Web Store for version information once every few hours.
While it would be possible for Google to make this push-based, I think this remains in place as a natural load-balancer (not everyone trying to update at once) and a bit of a safety net in case you published something badly broken.
On the extension side, there are 2 things in the chrome.runtime API that can influence the process.
You can force a check for a new version with chrome.runtime.requestUpdateCheck(). Note that this is rate-limited - you can't check too often.
In principle you could use some other method of delivering a notification to your extension (GCM, WebSockets to your server, polling your server etc.) to discover an update and trigger this check.
You can delay an update after it was detected with a listener to chrome.runtime.onUpdateAvailable event. It can be delayed no longer than the next browser restart.
If your extension has a lot of users (this starts at 10k users), there's an additional option available in the Dashboard's edit item interface.
Is it possible to perform a partial roll out in the Chrome web store?
CWS offers an option to only offer this version to a developer-specified percentage of users. This way you can limit the damage from a bad update.
Some browsers does not asks the client if he want use the application cache, but simply just downloads the whole thing at first visist (e.g. the browser on android). That can cause troubles when the application cache is many MB's and the client is on a mobile network - that is expensive! And is it possible to stop the cache from being downloaded? Pressing the menu button on e.g. android will not close the browser, it will be running in the background.
Is it a good idea to only add the manifest based on a cookie set when the client pushes a "hey i want to offline cache this site" button? Will that cause any new challenges?
I've tested this, and it seems to work. Needs more testing though. Can provide a link to the site in about two weeks if anyone is interrested.
One possible solution, as a you hinted at yourself, would be to ask the user if he/she wants to cache the app offline, and if so, only then redirect to a page which has a link to the manifest file (which is subsequently downloaded by the browser). You cannot stop a download midway unless of course, your network disconnects mid way.