1314922 - implement chrome.runtime.requestUpdateCheck

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[sixtyten]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161027110534

Steps to reproduce:

A number of extensions need this API: https://www.google.de/search?q=site:bugzilla.mozilla.org+requestUpdateCheck
Specifically, if you have a NativeMessaging binary that goes through incompatible changes while the browser is still running, you can't force an update check to update the extension along with the binary, but have to wait for a manual/automatic update or a browser restart.

For the case of registry-installed extensions, there is also bug 1313695.

Comment 1

[Caitlin Neiman [:caitmuenster]]

To be discussed at Nov. 29, 2016 WE triage meeting. 

Agenda: https://docs.google.com/document/d/1IMBFXHNpg_A-15VdJM1Hh8DUUXF1xNFy87W1w8ZEOBk/edit?usp=sharing

Comment 2

[Andy McKay]

Kris and I examined the Chrome extensions that used this and couldn't find a compelling reason to implement this based on their use case. With any extension, there's going to be services they speak to (Firefox, a server, a native messaging client) that all could be out of sync at any time and that's something an extension developer has to live with anyway.

There's already update checks in Firefox and they are done in the background to prevent any perceived jank or hang. As such triggering one from add-on causes us concern too.

At this point we felt that this should be won't fix, Kris please correct me if I'm wrong.

Comment 3

[sixtyten]

>Firefox, a server, a native messaging client [...] could be out of sync at any time and that's something an extension developer has to live with anyway.
But it's something I'd rather not live with as long as I have the choice. Each of these incompatibilities is responsible for compatibility code that wouldn't have to exist if one could force an update of at least one side, and some of this compatibility code is responsible for disproportional amounts of work (think "supporting IE6").

Consider my usecase: My extension talks to a large and complex application (https://4tiitoo.com/nui-sensor-technologies/ if you're interested) that has no notion of backwards compatibility between its components because it's only ever been shipped monolithically. In the extension, I've already implemented backwards compatibility with old versions of the application since the Chrome extension model doesn't let you pin extension versions to old ones after an extension update (understandable, imo, but a pain). But short of sending code over the native messaging channel to eval in the browser with chrome privileges, or prompting the user to restart their browser or manually update their extensions, I can't support arbitrary future versions of the application in the extension. Implementing the same kind of backwards compatibility in the application as there is in the extension is not an option since we're talking (at least) several man-weeks of work here and a lot of added complexity.
Without a mechanism to force updates, I'm looking at a time window of several hours after an application update where interaction is, at worst, simply broken.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1313695#c2.

Also consider enterprise usecases with similar setups.

If it's AMO resource usage you worry about, why not force extension authors to host their own update servers and provide this API only then? Or allow it only for extensions installed through a local file, or require special rights on the host.

Comment 4

[sixtyten]

PS: I don't understand why an asynchronous update check as offered by this API would/should cause jank/hangs if done properly?

Comment 5

[Andy McKay]

AMO usage isn't a concern. The primary concern is how this could possibly affect the browser as it triggers an update and handling threads to prevent hangs and jank. As you say if its "properly implemented" this shouldn't be a concern. Would this be something you'd be willing to implement?

Comment 6

[sixtyten]

I'd certainly be willing to do this, but we've looked at how much time it would take me compared to a hack solution on our end and decided that, for the time being, we'll simply prompt the user to restart Firefox. Maybe some later day.

Comment 7

[Andy McKay]

Just out of curiosity, how important is the response to you? I noted that we could just fire the update timer and let Firefox take care of the update. 

https://addons.mozilla.org/en-US/firefox/addon/timer-fire/

Is quite useful for debugging and basically does this:

function fireTimerCallback(contract) {
  if (contract in Components.classes) {
    Components.classes[contract].getService(Components.interfaces.nsITimerCallback)
                                .notify(null);
  }
}

function fireTimer(id) {
  switch (id) {
  case "background-update-timer":
    fireTimerCallback("@mozilla.org/updates/update-service;1");
    break;
  case "addon-background-update-timer":
    fireTimerCallback("@mozilla.org/extensions/manager;1");
    fireTimerCallback("@mozilla.org/addons/integration;1");
    break;
...
}

In this case the update check would fire, but you wouldn't be notified of the results. Would that be of use to you?

Comment 8

[sixtyten]

Useful but not critical. In the Chrome implementation, I currently use the response for diagnostic messages to the user (throttled/no_update), but these can be made less specific if need be. In case an update is available (update_available), I already rely on the browser to reload the extension and have no logic for that myself.

Comment 9

[sixtyten]

Oh, and to answer the second question: It definitely looks like it'd be of use to me (as long as the browser updates the extension shortly after the check). I don't need the answer that badly.

Comment 10

[TheRave]

My use case is very simple. After adding a new permission, the update hangs with a yellow exclamation mark at the hamburger menu. I have a lot users which are not recognize the yellow symbol as an notification where an action is required. They see it every day, it it is normal. No matter if i send emails to look for the exclamation mark to get the update, 50% of my users hang on an old outdated version, this is visible at addons.mozilla.org dashboard.

I have checked what i can do to make my own notification if an update is available and found that requestUpdateCheck is not yet implemented at Firefox. So i will make a XHR request now to examine the updates.json on update server.

But also here i have to add a new permission to get the XHR request working with potential to lost again users or i spend some work to optional permissions and hope that not so many users click this simply away and confirm this.

Comment 11

[Rob Wu [:robwu]]

@mkaply In the other bug you mentioned that this is important for enterprise. What use cases have you encountered?

Personally I am not opposed to this feature request.