--
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/79dcf744-5d56-4a7a-bf08-004e28e8d35b%40chromium.org.
console.time(1);
chrome.runtime.sendMessage(1, () => console.timeEnd(1));
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
sendResponse();
});
[I]t would be extremely helpful to have precise rules for when service workers terminate. - Scott
Why can't you at least support XMLHttpRequest inside extension service workers so we could use it with responseType='document'? - wOxxOm
Remind what were you telling us about service workers improving performance. - wOxxOm
Extension authors will have to use hacks like keeping a message port open to imitate persistent background pages in case they want to keep providing the previously guaranteed level of responsiveness to their users. - wOxxOm
Will there be a blog post or other linkable announcement containing the meat of this message - Kent
Excellent, thanks! Will there be a blog post or other linkable announcement containing the meat of this message? I'm relaying to many other developers in our organization and a static URL would be very helpful.
Thanks very much,
--Kent
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
Is Chrome Canary not supported on Linux? When will the MV3 preview land in a browser that is supported on Linux? - Alex
If Chrome terminates the worker while another party is waiting a message response from it, that would be a definite bug as that breaks the functionality of extensions… - wOxxOm
The browser can terminate a running SW thread at almost any time. Chrome terminates a SW if the SW has been idle for 30 seconds. Chrome also detects long-running workers and terminates them. It does this if an event takes more than 5 minutes to settle, or if the worker is busy running synchronous JavaScript and does not respond to a ping within 30 seconds.
A user agent may terminate service workers at any time it:
even if Chrome will be able to terminate the worker while keeping the messaging port open - wOxxOm
FWIW, disregard my earlier measurements, it was some weird local bug which I can't reproduce anymore. Today I see ~70ms for service worker and ~80ms for an event page so service workers wake up a little faster indeed. - wOxxOm
What will happen with chrome.webRequest.onAuthRequired -- it requires blocking web request for user to provide proxy credentials. - ilyaigpetrov
[1] I would like that Google fixes this regression by exposing an API to parse the DOM and send XHRs in service workers used as background scripts. [2] Otherwise, what justification should I give to users to explain them why the auto-save has been removed from "SingleFile Lite" (it will probably be a "lite" version on Chrome in the future)? … [3](the post https://github.com/w3c/ServiceWorker/issues/846 does not even talk about the specific issue in web extensions)? - Gildas
With the move from background pages to service workers, it now seems impossible to have something running persistently in the background. My extension needs to have a persistent background script so that I can store sensitive user data (decryption key) in memory. - Brendan
Linux users can test ManifestV3 extensions in Chromium snapshot builds like e.g. r712021 (download and unpack chrome-linux.zip).
--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/hG6ymUx7NoQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/63449686-a121-40c7-bd8b-7fb6f8a183b1%40chromium.org.
To unsubscribe from this group and all its topics, send an email to chromium-extensions+unsub...@chromium.org.
To unsubscribe from this group and all its topics, 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/63449686-a121-40c7-bd8b-7fb6f8a183b1%40chromium.org.
--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/hG6ymUx7NoQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/251317c2-a4ba-4323-a194-29bd67647d6f%40chromium.org.
[1] I would like that Google fixes this regression by exposing an API to parse the DOM and send XHRs in service workers used as background scripts. [2] Otherwise, what justification should I give to users to explain them why the auto-save has been removed from "SingleFile Lite" (it will probably be a "lite" version on Chrome in the future)? … [3](the post https://github.com/w3c/ServiceWorker/issues/846 does not even talk about the specific issue in web extensions)? - GildasI added some numbers in brackets to Gildas' comment in order to address a couple different points.[1]: Speaking extemporaneously, XHR in service workers feels to me like an unlikely solution. Per MDN, service workers were "designed to be fully async; as a consequence, APIs such as synchronous XHR and localStorage can't be used inside a service worker." You can retrieve web resources using the fetch API, but fetch also doesn't directly parse documents like XHR does (see HTML in XHR on MDN). This is a use case I want to address, I just don't think this is the right approach.[2]: I'd encourage you to consider other ways of accomplishing your goals. For example, if the user wants to enable auto-save, you could create a dedicated tab for this purpose. This tab would be a long lived environment under the user's control that would handle autosave document parsing & assembly. If the user closes the tab, you could use the notifications API and/or browser action icon to inform them that autosave has been disabled and give the user a chance to create a new tab to resume autosave. Alternatively, a less user-friendly approach would be to automatically create a new window/tab if the previous one is closed.[3]: You're correct, that issue does not mention extensions for a couple of reasons. First, all of the comments on that issue predate the public announcement that Chromium plans to move from background pages to service workers in MV3, so this use case couldn't have been discussed. Second, service workers are a web platform feature, not an extensions-specific feature. That repo is focused on specifying service workers for use in the open web. Third, browser extensions are a feature of web browsers, not a web platform feature. While browser extensions may come up when discussing specs, they're a tangential concern from the point of view of the open web.To the best of my knowledge "web extensions" is the name Firefox uses to refer to their browser extensions platform.Finally, the point I was attempting to get at in the comment Gildas is responding to was that not being able to parse documents also affects the open web as website's service worker can't parse, say, an XML feed and inform the user that new content is available. Chrome tends to approach its browser extension platform as being an augmentation and broadening of the open web's capabilities. Given that, I expect we'll be talking to the appropriate teams in Chrome and trying to push for a solution that works for the web, not just our extensions platform.
To unsubscribe from this group and all its topics, send an email to chromium-extensions+unsub...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/63449686-a121-40c7-bd8b-7fb6f8a183b1%40chromium.org.
--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/hG6ymUx7NoQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extensions+unsub...@chromium.org.
You can't throw in the top (global) context of the worker because it won't be registered.
--
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/8b284c81-6bcf-4517-9460-b4c83921630a%40chromium.org.
Similar issue -- I use chrome.downloads and my extension opens up a new tab when you download from a specific webpage. But I cannot specify a specific site or page in my manifest permissions. It's just "downloads", and my code is executed on every download from any site. I ignore the cases where the finalUrl is not the one I care about.
"permissions": [
"downloads"
],
I would have expected to see something like this:
"permissions": [
"downloads",
],
--
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/1a43bd8e-e43b-4a71-8db9-9b0b6d2420fb%40chromium.org.
I would have expected to see something like this:
"permissions": [
"downloads",
],
"permissions": {
"downloads.onCreated": {
"match": [
]
}
}
And similarly every leaf function interface could be a valid permission key and the values would be the more specific limitations of the permissions for that function.
Anyway, this gets pretty wishy-washy without any input from the developers.
Greetings extensions devs,I'm pleased to announce that as of October 31st, the Manifest V3 developer preview is now available in Canary.What does "developer preview" mean?Think of it as an early alpha. The "dev preview" is the first opportunity for extensions developers to start experimenting with a work-in-progress version of the MV3 platform.What to expectWe're far from finished with the implementation work on the MV3 platform, so first and foremost expect changes.As for what's changing, the four big-ticket items in MV3 are:
- Host permissions changes
- Blocking webRequest -> declarativeNetRequest
- Background page -> service workers
- Remotely hosted code restrictions
The declarativeNetRequest API has already been available for experimentation in Chrome Canary and we're continuing to iterate on it's capabilities. Background service workers are now available for testing in manifest version 2 and 3 extensions in Canary. Both remotely hosted code restrictions and host permissions changes are currently a work in progress. Some host permissions changes landed in Chrome Stable last year and additional changes will be available for testing in Chrome Canary in the coming months.Each of these features are in different stages of readiness, with some having partial capabilities and others being very early in the implementation process. Please remember that we're still early; additional (possibly breaking) changes are coming.Migration guideIn order to help developers start experimenting with and transitioning to MV3 we've put together a migration guide. This doc provides a high-level look at what's changing and what developers will need to do to adapt. We also have a guide specifically for migrating from background pages to service workers.I want to make sure the migration guide is useful for extension developers, so if you have any feedback on it reply to this thread.Happy coding,Simeon - @dotprotoExtensions Developer Advocate
--
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/79dcf744-5d56-4a7a-bf08-004e28e8d35b%40chromium.org.
--
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/004d0b7f-5d8e-4e7c-a583-e66089623ef7%40chromium.org.
Regarding 2 - a service worker is a type of worker. A worker is a script that runs in a different thread, it is not a document/HTML, it is strictly a script, so it makes sense that you cannot specify an HTML as a service worker, because this is how the web platform works, you register a JavaScript file as a service worker, not a document.
--
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/5caaa0d6-a988-421d-8740-af4d34ee1cbb%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
(Service) workers can import scripts using importScripts/dynamic import (I think regular module import statements are being considered as well)
Hi-priority ISSUE: Our extension uses Native Messaging. Each time extension refreshed from the Extensions page (for debugging purposes) old Native Host left running under Windows. Thus after one hour of working on the DOMXml issue from 1) I got ~20 running old Native Hosts applications!!!
Are you required to switch to service worker (non-persistent) background pages if you need to continue using non-blocking webRequest?
-Alex
What's the mechanism for learning what declarativeNetRequest did (which requests were blocked/redirected) on a given tab?
-Alex
What is going to happen with sandboxed pages? Are they converting to sandboxed service workers?Also, in the docs it is stated that fetching and evaling the code from outside will be impossible. Does this also apply to sandboxed pages(service workers)? In other words, can we eval in sandboxes with no access to chrome.* API?
-Yura Yazlovytskyy
0) USABILITY: Guys, why don't you describe where the Console for new Service Workers is in your article "Migrating from Background Pages to Service Workers"? I spent 3 days to find that I need to push "Inspect" button! Before it I saw just source code of Service Worker, also when I had errors clicking of red cross also displays some Console but not for Service Workers with some strange messages in it. And even more I find the description where to find Service Workers in Developers tools panel from some extension developer which is definitely not from Chrome developers team. Or am I expect too much from Chrome team?
- Aleksandr G.
3) ISSUE: Call to chrome.browserAction.setIcon() failed with text: "ReferenceError: Image is not defined". In fact my code is the same as in Manifest V2:
- Aleksandr G.
My extension, for security enhancements, blocks requests based on user form input. Meaning the extension opens up a request package --> run some validation code --> then decides to block / not block the request. How to achieve this usecase by the new non-block webrequest API and the declarativeNetRequest API? I could try to add a rule dynamically on a form submit event but the submit might already be hitting the networks.. and the added rule was simply too late to block the request?? Do I understand it correctly or I miss something?
- Panja
This issue also reproduced in another case: after some timeout (which is always different and can't be somehow calculated, it could be ~20 seconds after browser started or even half an hour) the browser restarts the Service Worker which leads to blinking the extension BrowserAction icon (we use 2 different icons depending on the product state) in the toolbar and starting new Native Messaging Host instance. Also sometimes browser crashes without any reason for that.
- Aleksandr G.
As far as I know, no one does any routine manual reviews for CWS: they are completely automated
- Anton Bershanskiy
Not everyone (me) feels comfortable revealing their name.Regarding Googlers or not, it is hard to know. I am not using Google Group, but e-mail instead, so when I hover over the sender, it usually shows whether it is a @chromium.org (or @google.com) e-mail or not. If it is a @chromium.org, then there is about an 80% chance it is a Googler.☆PhistucK
On Tue, Dec 3, 2019 at 7:52 PM Kent Brewster wrote:
Great, thanks!
Sorry for the confusion. I find myself wishing -- not for the first time -- that people would use their actual human names on this forum and that there was an easy way to tell who works at Google or on the Chromium project.
--Kent
> On Dec 3, 2019, at 9:44 AM, PhistucK wrote:
>
> See the reply by wOxxOm.
>
> I am guessing Webpack can support importScripts as well, so even without proper module support, you can still separate stuff (I agree it would be less comfortable than proper modules and will require code modification when you switch to proper modules).
>
> ☆PhistucK
>
>
> On Tue, Dec 3, 2019 at 7:37 PM Kent Brewster wrote:
Greetings extensions devs,I'm pleased to announce that as of October 31st, the Manifest V3 developer preview is now available in Canary.What does "developer preview" mean?Think of it as an early alpha. The "dev preview" is the first opportunity for extensions developers to start experimenting with a work-in-progress version of the MV3 platform.What to expectWe're far from finished with the implementation work on the MV3 platform, so first and foremost expect changes.As for what's changing, the four big-ticket items in MV3 are:
- Host permissions changes
- Blocking webRequest -> declarativeNetRequest
- Background page -> service workers
- Remotely hosted code restrictions
The declarativeNetRequest API has already been available for experimentation in Chrome Canary and we're continuing to iterate on it's capabilities. Background service workers are now available for testing in manifest version 2 and 3 extensions in Canary. Both remotely hosted code restrictions and host permissions changes are currently a work in progress. Some host permissions changes landed in Chrome Stable last year and additional changes will be available for testing in Chrome Canary in the coming months.Each of these features are in different stages of readiness, with some having partial capabilities and others being very early in the implementation process. Please remember that we're still early; additional (possibly breaking) changes are coming.Migration guideIn order to help developers start experimenting with and transitioning to MV3 we've put together a migration guide. This doc provides a high-level look at what's changing and what developers will need to do to adapt. We also have a guide specifically for migrating from background pages to service workers.I want to make sure the migration guide is useful for extension developers, so if you have any feedback on it reply to this thread.Happy coding,