background.js Uncaught ReferenceError: chrome is not defined

[WU RUXU]

Hi guys

    I have write an extension supported webview in android platform, but after I load extension background.js ,  Uncaught ReferenceError: chrome is not defined  , console.log is work okay.

walleye:/data/local/tmp/skyblue_ext # cat background.js
const user = {
  username: 'android-demo-user'
};

console.log(" *** This is a demo console message from background.js");
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  // 2. A page requested user data, respond with a copy of `user`
  console.log("onMessage:  " + message);
  if (message === 'get-user-data') {
    sendResponse(user);
    console.log("background.js send Response");
  }
});

chrome.runtime.xxxx works in content-script.js, only background.js isn't work

I found that background.js is start in service_worker, 

How can i inject chrome object in service_worker ?

Thanks very much

[Jackie Han]

Chrome does not support extensions on Android.

On desktop Chrome, `chrome` object exists in all web pages, and does not exist in service worker. I think it is the same on Android.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/83430498-4357-476e-9625-eead6dc443c3n%40chromium.org.

[WU RUXU]

yes, android does not supported.

but I have modified source code of chromium repo ,  my extension supported webview based on //content  and //extension 

Now my demo app can load extension, and load content-script.js as excepted,  but when I load background.js ,  error " Uncaught ReferenceError: chrome is not defined " output from service_worker  

[wOxxOm]

Sounds like a bug in your build of Chrome or in your extension. You can start by ensuring that existing MV3 extensions with a background service worker run successfully. You can also use demo extensions from the documentation.

[WU RUXU]

service worker should run successfully, because ' console.log(xxxx);' print output  in background.js 

[wOxxOm]

"Successfully" means that "chrome" works, which is not the case in your build of chrome, which is why I suggest you to isolate the problem by loading an extension that is guaranteed to run in normal Chrome and not have mistakes in the code.

[WU RUXU]

yes, my extension can works in offical chrome

[wOxxOm]

Then it's a bug in your build of Chrome. I don't think anyone in this group builds Chrome themselves though... Try asking in Chromium IRC channel.

[hrg...@gmail.com]

Keep in mind as well that Google will add extension support to Chrome on Android in the near future. This is why the Extensions Team insisted so stubbornly on removing the persistent background page in Manifest V3. This change is necessary to comply with an Android limitation that forces processes to terminate at any given moment (i.e. persistent background processes are not possible under Android).

So, after MV3 becomes mandatory in January 2023, the Chrome Web Store will no longer contain MV2 extensions (which are incompatible with Android) and so they'll have a clear path ahead to deploy the long-awaited extension support under Android.

[Jackie Han]

This change is necessary to comply with an Android limitation that forces processes to terminate at any given moment

If Google will support Android, another strategy could be:

1) let persistent background only be used on desktop;

2) let some apis only be available on desktop;

3) in manifest.json, add "platform": ["desktop"] or "platform": ["desktop", "android"]

[hrg...@gmail.com]

That would've been the ideal solution for us, developers, but Google doesn't care about extension developers, as there's no business to be made in that area.

They prefer to force developers to spend countless man-hours of our own time to migrate the entire CWS to a non-persisten model. They get it for free.

We've effectively became Google's slaves. We have to work for them with no recompense.

[Jackie Han]

The usage scenarios on mobile are significantly different than on desktop, and I don't think mobile browser support for extensions will allow the web to surpass native apps. As you can imagine, what mobile users want most is ad-block extension, not general tools.

[hrg...@gmail.com]

What's your point?

That Google should allow persistent processes in desktop platforms?

[Jackie Han]

What's your point?

My point is MV3 isn't just for Android.

[hrg...@gmail.com]

Of course it isn't. MV3 is a combination of changes, such as the declarativeNetRequest API which is more efficient because it doesn't need to invoke the extension's Javascript code. Or the removal of remote code execution, which allows Google to reduce the cost of reviewing extensions.

Different changes have different aims. MV3 is just an unrelated collection of changes.

The removal of the background page, in particular, is necessary for Android.

[Jackie Han]

Of course, the persistent background page can't work on Android. I didn't deny it. I just replied that there are other strategies to design extensions for Android.

[wOxxOm]

Persistent background pages can work on Android and there are several Chromium-based browsers like Yandex or Kiwi that implement MV2 extensions on Android. I've been using them for years.

[Jackie Han]

I don't know their implementations. (just guess) maybe the browser restarts persistent background pages when the browser is in the foreground.

[wOxxOm]

Their implementation matches the desktop implementation. The background page is truly persistent.

[hrg...@gmail.com]

Those browsers that support MV2 extensions only do their best attempt at keeping a process running for as long as possible, but it cannot be guaranteed. The Android kernel retains for itself the right to kill any process if it deems it necessary.

You can learn more about that here:

https://developer.android.com/guide/components/activities/process-lifecycle

[wOxxOm]

Assuming they use services for extensions, the inactivity timeout is 30 minutes, which is quite a reasonable number, which is probably why I never encountered any problems - my browsing sessions were shorter. I wish Chrome extensions use the same inactivity timeout (30 minutes) instead of the measly 30 seconds that causes frequent restarts that waste much more resources (CPU/disk/battery) than the few megabytes of RAM it gives back.

[hrg...@gmail.com]

The life-time issue on Android is more serious than that. Here's an example: Let's say you are browsing the web and then you switch to another app (WhatsApp for example). Now the browser is no longer the foreground app, so if WhatsApp starts using too much RAM, the kernel will start killing non-essential processes to release RAM. And the only essential process from Android's perspective is the one the user is interacting with.

You see... not even the browser itself can be a persistent process. As soon as it's no longer the foreground app, it can be killed at any moment. There are no predictable timeouts that we, as developers, can rely on.

[wOxxOm]

Yeah, but as long as the browser is actively used, which is what I meant by a browsing session, Android provides a very reasonable timeout, unlike the ill-conceived 30 seconds in MV3...

[WU RUXU]

hi all

    I have fixed this issue in my android app