Add more offscreen reasons?

[Jackie Han]

We've just added a new WORKERS reason which can be used to spawn a worker from an offscreen document: https://chromium.googlesource.com/chromium/src.git/+/a8fe947f9d5737f4e36fe32ab8fa851ea6da8865. 

I have two extensions that can't upgrade to MV3.

1. Battery Status

Because service worker doesn't support battery status api, until issue-1280007 be fixed, the extension can't upgrade to MV3.

Could offscreen add a "Battery" reason for this?

Note that this is a persistent use case. Because the extension needs to listen to some events like 'levelchange'. If the offscreen document is closed, there is no way to know the battery level change event, so it needs to open forever.

2. System Monitor (rely on chrome.system.cpu and chrome.system.memory api)

This extension is very simple. It just updates the extension's badge text or icon every 1-5 seconds (yes, seconds, not minutes). 

Could offscreen add a "System" reason for this?

This is also a persistent use case. Because it will repeat forever. Imagine your operating system's built-in system monitor app updating CPU or memory usage every second.

Jackie Han

[Oliver Dunk]

Hi Jackie,

Thanks for letting us know about those.

I'm personally very keen to support as many use cases as possible - I'll pass these along to the team and make sure we give them some thought.

No promises but I'll share updates here if I get any :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
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/CAAgdh1KCLDCystDr52jQK7CS_5S0seSwJoi8UHBMrtFEYsBOOA%40mail.gmail.com.

[Jackie Han]

Thanks. These are two special cases that essentially rely on persistent background script (especially the second case). Most of my other extensions have already migrated to MV3.

By the way, the documentation does not have any detailed explanation of each type of Reason, they are just a word.

[Oliver Dunk]

That makes sense.

We do have some comments in the code which are likely helpful here: https://chromium.googlesource.com/chromium/src/+/main/extensions/common/api/offscreen.idl. I'll see about getting them to show up in the documentation - I'm honestly not sure why that isn't already the case. Thanks for pointing that out.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

What reason should I choose for the offscreen document when starting a Firestore snapshot (Firebase) there?

[Simeon Vincent]

I'll see about getting them to show up in the documentation - I'm honestly not sure why that isn't already the case. Thanks for pointing that out.

I think this was just an oversight in how the current system works when it was first implemented. I'm not aware of any specific reasons descriptions were omitted from enum values.

What reason should I choose for the offscreen document when starting a Firestore snapshot (Firebase) there?

I think IFRAME_SCRIPTING is the best fit.

Simeon - @dotproto

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/dad3d68e-1360-483d-9dec-167cd382a9d2n%40chromium.org.

--

Simeon

Developer Advocate, Chrome

@dotproto

[Oliver Dunk]

I think this was just an oversight in how the current system works when it was first implemented. I'm not aware of any specific reasons descriptions were omitted from enum values.

Yeah, I agree. I've brought this up internally so hopefully we can fix it soon.

I think IFRAME_SCRIPTING is the best fit.

Hmm. Uladzimir, am I understanding correctly that this is basically using WebSockets? If so, I'm not sure any of the reasons fit. I do know that WebSocket type functionality is something we know is missing. I'm hoping we can provide something there.

Jackie - on your two use cases, I spoke to the engineering team about them:

• We're currently looking in to whether we could support the Battery Status API in service workers. Given that, we're a little reluctant to add an offscreen document reason too soon that may very quickly be replaced. Hopefully that makes sense.
• For system.cpu and system.memory, is there a reason why you can't call this in the background page? Is it just the frequency of the updates you're worried about? If so I understand the use case but I'm not sure offscreen documents is the right solution.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Jackie Han]

For system.cpu and system.memory, is there a reason why you can't call this in the background page? Is it just the frequency of the updates you're worried about? If so I understand the use case but I'm not sure offscreen documents is the right solution.

In fact, it only needs service workers to be persistent, it doesn't need offscreen. But MV3 doesn't support persistent background page, so use offscreen's unlimited lifecycle as a workaround to keep service worker persistent.

[Oliver Dunk]

In fact, it only needs service workers to be persistent, it doesn't need offscreen. But MV3 doesn't support persistent background page, so use offscreen's unlimited lifecycle as a workaround to keep service worker persistent.

That makes sense. I'd encourage you to give implementing it a try and see how it works out. Given the changes in https://developer.chrome.com/blog/longer-esw-lifetimes/, I think frequently requesting the system state and updating the icon may actually be enough activity to keep your service worker alive.

You could potentially register an alarm too. That way in the worst case you fallback to updating once a minute.

I understand that neither of these are perfect, so will still pass along the feedback - but just suggesting things that may unblock you in the short term.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

Oliver, I'm not sure what technological solution is behind this - https://firebase.google.com/docs/firestore/query-data/listen

But it already works.

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Jackie Han]

Given the changes in https://developer.chrome.com/blog/longer-esw-lifetimes/, I think frequently requesting the system state and updating the icon may actually be enough activity to keep your service worker alive.

No, I don't think so. setInterval/setTimeout in service worker can't prolong service worker life. Insead, in offscreen document, keep sending messages can prolong service worker life, that is what I mean.

[Oliver Dunk]

You're right that setInterval doesn't extend the lifetime, but calls to chrome extension APIs can. I think it's definitely worth a try.

(I want us to look at improving the documentation around this because I think the blog post is accurate, but a little vague on exactly how we define certain behaviour)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB