cc atwilson@ for background mode.

I agree this would be a nice fix, but is unlikely to be something we tackle in the immediate future.  Marking as Available so that someone can grab this if they have the cycles.  As a workaround, extensions can control when they choose to update (Chrome shouldn't forcibly shut them down), so they can avoid updating if they are the only thing keeping the browser alive.

Thanks for filing the issue!

@Reporter: Could you please provide sample test extension/URL that reproduces the issue which helps us in further triaging it.

Thanks!

I don't quite understand - if you run chrome with --no-startup-window, what is supposed to make Chrome exit?

What's the status of the kBackgroundModeEnabled pref?

Chrome is supposed to exit once there are no open windows OR running background pages.

What's probably happening is that, when no windows are open, the only extension with a running background page is updated and then restarted -- but during restart of the extension, the extension's background page is killed and since it was the only thing keeping Chrome alive, Chrome is shut down as a result.

HI All,
  Just update the bug with the enterprises use case to fill in the use case.

Here are the file contents from the demo and a short guide on how to reproduce the problem.

Flow to reproduce:

1.       Create an extension using the file contents below with a version of 1.0.0

2.       Install the extension in Chrome

3.       Fully close Chrome (no processes running)

4.       Create a 2.0.0 version of the extension and the update.xml

5.       Copy the extension and update xml to the directory specified in the manifest update_url

6.       Start Chrome with --silent-launch

7.       Chrome will start, begin the process of updating the extension, then exit

8.       Restart Chrome and the extension will be updated to 2.0.0

 

 

manifest.json

{

        // Required information

        "manifest_version": 2, // Manifest version must be 2 without quotes

        "name": "Extension", // Name of the extension

        "version": "1.0.0", // Version of the extension

        "update_url": "file:///C:/Users/itg2539/Desktop/GoogleDemo/Current/Update.xml",

        "background": {

                "scripts": ["index.js"],

                "persistent":true

        },

        "permissions": [

                "tabs",

                "storage",

                "nativeMessaging",

                "background",

                "cookies",

                "webRequest",

                "webRequestBlocking",

                "webNavigation",

                "<all_urls>"

        ]

}

 

Index.js

chrome.runtime.onUpdateAvailable.addListener(function(details) {

    console.log("updating to version " + details.version);

    chrome.runtime.reload();

});

 

chrome.runtime.requestUpdateCheck(function(status) {

    if (status == "update_available") {

        console.log("update pending...");

    } else if (status == "no_update") {

        console.log("no update found");

    } else if (status == "throttled") {

        console.log("Oops, I'm asking too frequently - I need to back off.");

    }

});

 

Update.xml

<?xml version='1.0' encoding='UTF-8'?>

<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>

  <app appid='kcamabijaojcfjimhgcmmppakgjhlmkb'>

    <updatecheck codebase='file:///C:/Users/itg2539/Desktop/GoogleDemo/Current/Extension.crx' version='2.0.0' />

  </app>

</gupdate>

Removing from the enterprise triage queue - seems like the bug is on the edge between extensions and enterprise areas, and all respective owners are already on the bug.

c#6, step 7 shows the error. Chrome should not quit, but keep running and update the extension.

As an aside, I suspect a workaround might be passing --keep-alive-for-test as a command line switch.

Devlin, take a look at BackgroundApplicationListModel::Update(): https://cs.chromium.org/chromium/src/chrome/browser/background/background_application_list_model.cc?l=383

We call this when we're told that an extension is loaded/unloaded. We call ExtensionRegistry::enabled_extensions() - when an extension has been unloaded as part of an update, will enabled_extensions() still return that extension?

Because if not, then we have a problem because at that point we don't really have any way to know that there's a background extensions in the system. We *could* just skip updating our list of background extensions (check the UnloadedExtensionReason in our OnExtensionUnloaded() handler) but that feels fundamentally fragile (if there's an error reloading the extension post-update, then the browser will never exit).

Any guidance here?

> when an extension has been unloaded as part of an update, will enabled_extensions() still return that extension?

No (this is documented here [1]).  "enabled_extensions()" could perhaps better be thought of as "active extensions" - extensions that are, in some way, "running" (of course, this gets into shadier territory for event pages).

> We *could* just skip updating our list of background extensions (check the UnloadedExtensionReason in our OnExtensionUnloaded() handler) but that feels fundamentally fragile (if there's an error reloading the extension post-update, then the browser will never exit).

Yep, agreed.  Conceptually, the flow we'd have to do is:
- look for unload.
  - if unload for any reason other than reload, remove keepalive
  - if unload for reload, start observing reload notifications
    - on reload success, resume normal state
    - on reload failure, remove keepalive

+michaelpg@ implemented something similar to this in revision ffdb36ccd700313bf76362d79288fb677fcf4022 for AppShell (since the app may need to restart itself).  If we want to tackle this, it's probably best to lightly refactor that code to work for arbitrary apps/extensions and consume it in chrome (or in a shared space between appshell and chrome).

[1] https://chromium.googlesource.com/chromium/src/+/ffdb36ccd700313bf76362d79288fb677fcf4022/extensions/browser/extension_registry_observer.h#37

Thanks. +mheinsohn, is the --keep-alive-for-test switch a sufficient workaround for this issue? I'm somewhat loath to change this code unnecessarily.

OK, gonna WontFix this since I don't really want to touch that code, and this use case is a bit weird, and is probably satisfied with --keep-alive-for-test.

Can someone explain how --keep-alive-for-test is a valid workaround for this issue? The expectation is that the extension will cause Chrome to automatically run at startup which makes it very very difficult to use a different command line for the browser.