Announcement: Start experimenting with parts of MV3

[Simeon Vincent]

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 expect

We'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 guide

In 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 - @dotproto

Extensions Developer Advocate

[Scott Fortmann-Roe]

Thank you for this update.

In the service workers migration doc <https://developer.chrome.com/extensions/migrating_to_service_workers>, it would be extremely helpful to have precise rules for when service workers terminate. Understanding when service workers do or don't terminate is important to understanding what can be migrated from a background script and how to architect the service worker.

For example, I have a background script that receives messages for many user actions in a page. If this was ported to a service worker, would it be kept alive indefinitely as long as the user was carrying out actions and a message was sent to the service worker every few seconds?

--
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.

[wOxxOm]

The service worker migration document advises us to use a slow js library to parse DOM inside a browser (a program that's created to parse pages into DOM), which just doesn't make sense. Why can't you at least support XMLHttpRequest inside extension service workers so we could use it with responseType='document'? It'd be asynchronous, which is arguably a plus, but most importantly not as nonsensical as the advised approach.

[wOxxOm]

Waking up a service worker takes 320-350ms on 4GHz i7 using this simple content script on a dummy page like https://www.example.org/

console.time(1);
chrome.runtime.sendMessage(1, () => console.timeEnd(1));

and this background script:

chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  sendResponse();
});

This is absolutely ridiculous especially compared to 250-270ms needed to wake an MV2 event page. Remind what were you telling us about service workers improving performance. Oh I know, "we will work on improving it in the future", but I somehow doubt it'll improve by much. 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.

On Friday, November 1, 2019 at 8:02:14 AM UTC+3, Simeon Vincent wrote:

[Kent Brewster]

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

[Simeon Vincent]

[I]t would be extremely helpful to have precise rules for when service workers terminate. - Scott

Since service workers are a web technology rather than an extension-specific one, we probably won't have exhaustive docs here. I think it makes sense to link embellish the migration guide with links to resources like Jake Archibald's The Service Worker Lifecycle, the Service Workers 1 spec, and other docs that help folks understand this specific API. 

 

Why can't you at least support XMLHttpRequest inside extension service workers so we could use it with responseType='document'? - wOxxOm

 

The short answer is that service workers are a type of worker, and workers don't have access to XMLHttpRequest or DOMParser. The longer answer is that this is an unaddressed issue for the broader web platform. There's an open issue on the service worker repo (issue 846) where the spec authors & community members are discussing this capability. Broadly speaking, I think we'd prefer to see issues like this addressed at the platform level rather than creating a bespoke solution for extensions. 

 

I imagine we (Chrome & the extensions team) will continue discussing this over the coming months. No guarantees for any specific outcome here, but I for one very much want to see a better solution for document parsing.

 

Remind what were you telling us about service workers improving performance. - wOxxOm

 

Two things. First, please bear in mind that we’re essentially at alpha right now. The extensions team has been focusing on implementing functionality and hasn’t had a chance to polish implementations or optimize performance. This as compared to event pages, which have been around for a decade or so. To be honest, I’m actually pretty happy to see that we’re within striking distance of event pages.

 

Second, there are many aspects to "performance." Moving the platform from long-lived to an event-based background environment is the main goal with this change. This will mean fewer concurrent processes and less overall strain on the user's machine. Yes, some specific extensions will have performance regressions and will be slower. But on the whole we believe this change will be a net win.

 

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

 

I'd caution against going this route as per the ServiceWorker spec, "[s]ervice workers may be started by user agents without an attached document and may be killed by the user agent at nearly any time." 

 

Will there be a blog post or other linkable announcement containing the meat of this message - Kent

 

Not at this stage, no. The manifest V3 platform isn't feature complete or stable. We want developers to experiment and share feedback but we don’t want folks to assume MV3 is “ready.” We’re mostly trying to reach extension developers eager to experiment and explore, so we thought an announcement in this group was the best way to reach these folks. 

 

If you want to share links, the migration guide is probably your best bet. That URL should be stable even if we iterate on the documentation and Manifest V3 platform's implementation.

Cheers,

Simeon - @dotproto

Extensions Developer Advocate

On Friday, November 1, 2019 at 9:11:01 AM UTC-7, Kent Brewster wrote:

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

[Alexei Miagkov]

Is Chrome Canary not supported on Linux? When will the MV3 preview land in a browser that is supported on Linux?

[James Lewis]

Consider using a trunk build of Chromium, which is not far off from any given Canary release: No proprietary components are involved here, so the MV3 preview should exist there as in Canary.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[wOxxOm]

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, so the hack will work and will be [ab]used like I predicted at the very first announcement of MV3 draft.

P.S. and even if Chrome will be able to terminate the worker while keeping the messaging port open (er, really?), the hack would simply evolve to sending a new dummy message every 100ms so Chrome won't be able to make the decision to kill the worker.

[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. Nice.

[ilyaigpetrov]

What will happen with chrome.webRequest.onAuthRequired -- it requires blocking web request for user to provide proxy credentials.

[Gildas]

The short answer is that service workers are a type of worker, and workers don't have access to XMLHttpRequest or DOMParser. The longer answer is that this is an unaddressed issue for the broader web platform. There's an open issue on the service worker repo (issue 846) where the spec authors & community members are discussing this capability. Broadly speaking, I think we'd prefer to see issues like this addressed at the platform level rather than creating a bespoke solution for extensions.

I disagree. My extension is negatively impacted by this change. Because they can, Google decided to introduce a regression and potentially break existing extensions. 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. 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)? Google does not care or is too lazy (the post https://github.com/w3c/ServiceWorker/issues/846 does not even talk about the specific issue in web extensions)? Or maybe should I tell them a fake argument about "security" reasons?

[Jaime]

I will read it carefully, good information.

Nice day. Thanks Simeon.

[Brendan]

Hi Simeon,

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. Is there any way to store data that will be preserved across the session but not stored to disk in the background with manifest V3?

Regards,

Brendan

[Simeon Vincent]

Is Chrome Canary not supported on Linux? When will the MV3 preview land in a browser that is supported on Linux? - Alex

Unfortunately no, Canary is not supported on Linux. As James suggested you can manually build yourself. If you go this route, you might want to use Icecc to run distributed builds. An Igalia contributor wrote up a blog post that may help with this process. I've seen some folks report using Wine and the Windows version of Chrome Canary. That's out of my depth, but I figured I'd mention it as an option.

Alternatively you can wait until the changes land in Dev. I'm not sure what all is involved in that, but I'm planning to follow up on this next week.

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

While I understand where you're coming from, I don't think it's accurate from Chromium's point of view. The following passage is taken from the Chromium project's Service Worker Security FAQ:

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.

Additionally, from the Lifetime section of the service worker specification:

A user agent may terminate service workers at any time it:

• Has no event to handle.
• Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events.

Moreover, mitigations have already been put in place to prevent abusive use cases such as crypto miners juggling messages to extend their execution time.

TL:DR; artificially extending a service worker's lifespan is and expecting everything to work out just fine is … inadvisable.

even if Chrome will be able to terminate the worker while keeping the messaging port open - wOxxOm

I believe the port is closed when a service worker (or event page) is terminated.

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

Are you restarting Chrome between tests? I ask as that may affect what you're measuring. A clean start with minimal data cached and no installed extensions at startup may have different performance characteristics from a long browser session with a "warm" service worker or event page. Thinking out loud, I also wonder if V8 might optimize the service worker's script after repeated executions.

 

What will happen with chrome.webRequest.onAuthRequired -- it requires blocking web request for user to provide proxy credentials. - ilyaigpetrov

I know I've heard this mentioned, but unfortunately I can't remember off hand. I'll have to follow up on this next week.

[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

I 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.

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

We're aware of this use case and are considering ways to support it in MV3, but don't have anything firm to share with the broader community at the moment.

Cheers,

Simeon - @dotproto

Extensions Developer Advocate

[wOxxOm]

Re "emulated persistent workers": you're missing the point, I'm not talking about long-running tasks, just about having an open messaging port, so there'll be no task to terminate, and none of those conditions you've mentioned apply. Here's an example for event pages so you know how it's done currently: https://stackoverflow.com/a/58577052. In MV3 we can't create a background iframe, obviously, so we'll have to use a random tab's content script. This is working right now. This will always be working. There's nothing Chrome can do to detect or prevent it and there will never be because it's just a normal delayed messaging.

Re "wake up time measurements", the slow performance could have been caused either by Canary being a DCHECK build (I didn't confirm at the time and now it's updated) or something running in the background locally. I will keep an eye on it in the future anyway.

[ilyaigpetrov]

Thank you, Simeon, for your reply.

There is one more question I would like to know about -- what will happen to chrome.proxy API and remotely hosted PAC-scripts in particular.

[wOxxOm]

Linux users can test ManifestV3 extensions in Chromium snapshot builds like e.g. r712021 (download and unpack chrome-linux.zip).

To download the latest build for your OS use https://download-chromium.appspot.com

I can't test MacOS, though.

Simeon, can you test this and add to the announcement/documentation?

[ilyaigpetrov]

Linux users can test ManifestV3 extensions in Chromium snapshot builds like e.g. r712021 (download and unpack chrome-linux.zip).

i've downloaded 712021 for Linux -- it gives me an error: The maximum currently-supported manifest version is 2, but this is 3. Certain features may not work as expected.

[wOxxOm]

The functionality is there so simply ignore this error which only reminds you to expect bugs. The phrasing can be improved though (pinging @Simeon).

[ilyaigpetrov]

In the service worker script I try adding console.log and throwing an error.

However no error is shown on chrome://extensions and I also don't know where my logs go because I see no way to open devtools for inspecting a service worker.

Here is my manifest.json:

{ "manifest_version": 3, "name": "MV3 Test", "version": "0", "permissions": [ "webNavigation", "tabs" ], "background": { "service_worker": "./bg.js" } }Here is the content of bg.js:'use strict'; console.log('Extension started.'); throw new Error('HELLO THERE');

[wOxxOm]

Service workers can be inspected on any tab using devtools:

Application tab =>

Service Workers (on the left) =>

Service workers from other origins =>

chrome-extension://your-id/bg.js => Inspect

Hopefully they'll hook it on chrome://extensions page in the future because currently it's extremely inconvenient.

[wOxxOm]

Also via chrome://inspect/#service-workers

[ilyaigpetrov]

My steps:

1) Install extension from a directory.

2) Ignore manifest versions error/warning.

3) Open some tab (google.com) -> Application -> service workers

4) I see no service workers installed absolutely.

5) Open chrome://inspect/#service-workers

6) I see no service worker absolutely.

--
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.

[wOxxOm]

Works for me in Linux Mint.

• in devtools you need to click "Service workers from other origins" as noted in my post
• chrome://inspect/#service-workers will only show currently running service workers, not the sleeping ones.

To unsubscribe from this group and all its topics, send an email to chromium-extensions+unsub...@chromium.org.

[ilyaigpetrov]

Thank you, wOxxOm. If found my service worker on devtools of a new tab after restarting my extension on chrome://extensions.

Maybe I was unlucky in my first attempt and service worker was terminated before I opened devtools.

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.

[Gildas]

On Sunday, November 3, 2019 at 12:48:25 AM UTC+1, Simeon Vincent wrote:

[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

I 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.

Thank you very much Simeon for your detailed answers, I really appreciate your commitment. I wished I could implement all the necessary changes you suggest to make the extension compliant with MV3. Unfortunately, this represents way too much work for me and I'll deceive users by having to remove or hack existing features. So, I won't port the code and I won't offer any "SingleFile Lite" compliant with MV3 requirements. The extension will be removed from the store of Google when MV2 extensions will be forbidden. This choice is also due to the new way extensions are reviewed which is incompatible with one-man projects for which you cannot afford a QA team.

[wOxxOm]

I've tried submitting an issue https://crbug.com/1020883 but the bug tracker became buggy itself and didn't post the actual text of the issue so I'll repeat it here:

chrome://extensions card and extension details page should show:

1) A dedicated link to open devtools for the extension service worker.

   Probably the script name, just like it was shown for MV2 extension's background page.

2) The worker's state.

   Probably just like the current MV2 adds "(Inactive)" on event pages.

Note: "developer mode" switch should be enabled first.

Currently we have to open devtools on an unrelated tab, switch to application panel, click "Service workers", click "Service workers from other origins", scroll or filter the potentially long list and find the one with nonsensical id hash in the URL that belongs to our extension. That's a huge amount of intermediate steps, quite a cognitive load to remember and recognize the id, and to learn the new way of inspecting the background script.

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.

[ilyaigpetrov]

I tried to create a worker which just throws an error but I can't find any ways to see the error thrown from my sw.

Once I open devtools for my worker its console is clear and chrome://extensions card doesn't show any error thrown by sw.

[wOxxOm]

You can't throw in the top (global) context of the worker because it won't be registered.

[ilyaigpetrov]

Could you, please, make error handling more easier in MV3.

Currently it's as inconvenient as MV2.

There is a related ticket for MV2 here: https://bugs.chromium.org/p/chromium/issues/detail?id=357568.

Here is an example for service worker inside MV3:

```js

console.log('Extension started.');

self.addEventListener('error', (event) => { console.log('WE HAVE AN ERROR HERE:', event); });

self.addEventListener('unhandledrejection', (event) => { console.log('THIS IS UNHANDLED:', event); });

// Case 3

chrome.tabs.getCurrent(() => {

  throw new Error('Chrome API callback (not caught by handlers but must be caught)');

});

// Case 4

chrome.tabs.getCurrent(() => setTimeout(() => {

  throw new Error('Timeouted Chrome API callback (caught by handlers)');

}, 0));

```

[Chris Zalcman]

After Google removing extensions and apps for no reason, fully regulating installation sources and users count under the guise of "bugs", 

do you think there's any reason to rewrite any good application to manifest 3? Wouldn't it be better to write independent software with nodejs,  

Electron... - Build cross platform desktop apps with JavaScript and redistribute as you want. As we can see G make sandbox 

for developers and will never let you and your apps get up, because all is under their control.

[Ergonomic Code]

This is another stupidest decision I've seen.

Chrome / Chromium has millions of other problems that have not been resolved for years.

- chrome.google.com/webstore - can you find something useful in this garbage dump?

- The interface that is pinned with nails. There is not even microscopic freedom to customize the interface.

- The Chrome homepage is made up of boards and nails. There are only 10 shortcut icons on it. And zero freedom of customization.

- Want to change keyboard shortcuts? Try it in another browser!

- Synchronization transfers only part of the settings to a new browser.

- I will not talk about the engine, which has accumulated a lot of junk code.

So I can go on for a very long time ...

But no, you need to break something again (ad blocking) without backward compatibility.

[wOxxOm]

Yep, the slow wake up time was caused by DCHECK Canary build as seen in menu Help=>About

Version 80.0.3958.1 (Official Build) canary-dcheck (32-bit)

IMO a highlighted warning should be added in the MV3 articles that Canary may be **randomly** updated to a superslow DCHECK build, @Simeon.

To disable this the users have to manually edit the registry:

https://crbug.com/873458

[HKEY_CURRENT_USER\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort]

"hint"="asan-optout"

On Sunday, November 3, 2019 at 2:48:25 AM UTC+3, Simeon Vincent wrote:

[ilyaigpetrov]

You can't throw in the top (global) context of the worker because it won't be registered.

I think if worker can't be registered because of such error then Chromium should notify user, e.g., via a card on chrome://extensions.

Should I create a ticket for this, what do you think?

Or maybe you've already created a similar one? 

[wOxxOm]

The bug tracker is currently broken, the text of posts/comments is not submitted.

[wOxxOm]

The bug tracker is working now so you can file a new issue.

On Monday, November 4, 2019 at 11:55:26 AM UTC+3, ilyaigpetrov wrote:

[Anton Bershanskiy]

It's nice to see that remotely hosted code is blocked, but there is one more security concern I have: very coarse permission system. Currently, users have to grant permissions to the whole top-level API interface, so if extension needs access to interface chrome.top.final the developer has to specify permission "top" and have access to all APIs in chrome.top. This is problematic because:

1. Minimum privilege principle is not satisfied
2. Users see a lot of powerful permission requests and grow complacent, get used to clicking "OK" and stop treating powerful permissions as something dangerous
   
3. Unscrupulous extension developers can ask user for permission to do one thing, but then secretly use it to do a completely unrelated thing
   

I believe the broad permissions can be replaced or augmented with more granular ones. For example, there are already granular permissions "system.cpu", "system.display", and "system.memory". Similarly, most top-level permissions could be replaced with second-level ones. For backwards compatibility, the top-level permissions can be just aliased to a union of all second-level permissions.

Here is a specific scenario that I have observed in the past:

Extension needs to prevent WebRTC IP sharing/leak, so it needs to access chrome.privacy.network, therefore developer requests "privacy" permission and has to explain to the users why extension needs permission to "Change your privacy-related settings". With more granular permission "privacy.network" Chrome could display a more specific warning like "Change your network settings related to privacy".

Sincerely,

Anton.

[John Dimm]

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.

--
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.

[Anton Bershanskiy]

On Monday, November 4, 2019 at 5:19:17 PM UTC-5, John Dimm wrote:

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.

Your issue would not be solved with individual permissions for every leaf interface, because you are asking fora different thing: ability to filter downloads by URL. That's an orthogonal idea to the one I proposed. It would be nice to have that kind of permission granularity, but your case is specific to this particular API (chrome.downloads.onCreated) and might require some API redesign, so is much more difficult to achieve. Also, I'm unsure what exactly your idea is (where exactly in the manifest you would specify the host/URL regex).

[John Dimm]

Instead of this:

  "permissions": [

          "downloads"

        ],

I would have expected to see something like this:

  "permissions": [

          "downloads",

          "https://mint.intuit.com/"

        ],

--

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.

[Anton Bershanskiy]

On Monday, November 4, 2019 at 10:02:54 PM UTC-5, John Dimm wrote:

I would have expected to see something like this:

  "permissions": [

          "downloads",

          "https://mint.intuit.com/"

        ],

This syntax looks a lot like just two different permissions: just "downloads" permission and a host permission "https://mint.intuit.com/". May be, something like this would be better:

  "permissions": {

     "downloads.onCreated": {

       "match": [

         "https://mint.intuit.com/"]

       ]

     }

   }

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.

[Aditya B]

Hi Simeon

Thanks for sharing this.

The documents on migrating to event pages or service workers do not specify how to use WebRequest API with them.

At the moment, event pages do not support the WebRequest API. So, how should I migrate my extension to event pages, and later to Service Workers?

Unlike the ad-blocker use case, I don't use WebRequest to block requests. I use the `onBeforeRedirect` event listener to listen for server redirects to keep track of duplicate pages. In this case the new declarativeNetRequest doesn't seem to be an alternative.

I have raised this in a separate thread as well.

Cheers!

Adi

[Simeon Vincent]

Hey all,

I just wanted to pop in real quick to say that I'm super overloaded with Chrome Developer Summit prep right now. Once the event passes and I catch my breath, I'll jump back in this thread to share more info, provide clarifications, gather feedback, and generally try to get back to being useful around these parts.

Thanks for your patience and understanding.

Cheers,

Simeon - @dotproto

Extensions Developer Advocate

[Alexei Miagkov]

Are you required to switch to service worker (non-persistent) background pages if you need to continue using non-blocking webRequest?

What's the mechanism for learning what declarativeNetRequest did (which requests were blocked/redirected) on a given tab?

On Fri, Nov 1, 2019 at 1:02 AM 'Simeon Vincent' via Chromium Extensions <chromium-...@chromium.org> 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 expect

We'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 guide

In 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 - @dotproto

Extensions 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.

[Yura Yazlovytskyy]

Thanks for the update Simeon.

A quick question( sorry if you have already mentioned this somewhere, I am not able to find the answer)

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?

Thank you,
Kind Regards,
- Yuriy

[Aleksandr G.]

Well, I'm working on Manifest V3 issue this week and got some questions, also found some bugs. Hope Simeon will hear me this time (as I wrote not once and didn't get even 1 character response).

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?

1) QUESTION: With all my respect towards Google why did Chrome developers team thrashed support of DOM (at least I'm speaking about XML) in the Service Workers? Who decided that no body will need it? I waste week of working time to find at least somehow working library with DOMXml support and write personal code which do the same things as already have in each browser: I'm talking here of Selectors API and in particular case DOM.querySelectorAll() and DOM.querySelector() methods. Don't you think that JS code will work much more slower than already existing browser binary code? You just forced thousands of Chrome extension developers to do the same thing as it was before with Internet Explore - do some fixes, patches to support IE in different versions.

2) ISSUE: Why Service Worker as HTML doesn't work? I'm talking about this code:

 "background": {

    "service_worker": "spBackgroundSW.html"

  }

Where inside spBackgroundSW.html we have:

<!DOCTYPE html>

<html>

<head>

  <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"/>

  <script src="spBackground.js"></script>

</head>

<body>

</body>

</html>

This works fine for Background script in Manifest V2. And we need it working for Manifest V3 as some scripts used by Service Worker are used also by content scripts!

Hope you don't want to force extension developers to duplicate the same code in different places (Service Worker, content script) of single extension?

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:

        chrome.browserAction.setIcon({

          path: {

            '16': 'skin/logo16.png',

            '20': 'skin/logo20.png',

            '32': 'skin/logo32.png'

          }

        });
    When this will be fixed?

4) 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!!!

[PhistucK]

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.

Regarding 1 - the web platform does not support DOM/XML in workers of any kind, so service workers in extensions also do not support DOM/XML. However, this is something that the web platform is considering in general and you are welcome to join the discussion (in a constructive way, "me, too" is not constructive) at https://github.com/w3c/ServiceWorker/issues/846.

Note that this is not an extension-specific discussion, but a general web platform specific discussion and extensions are not the main use case.

With that said, regular web pages need DOM/XML support as well in workers/service workers, so solving this problem would benefit the entire web community at large and not only Chrome extension developers (but it does make solving it more difficult, unfortunately).

☆PhistucK

--

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.

[Vasco Gomes]

After reading the migration guide, I'm shocked. The MV3 is going to trash my 20+ extension with +500k active users. Not a single extension can survive to this.

The worst thing is that MV3 will cripple and cease to function almost all current extensions. Stone by stone it kills webrequests or background pages.

I'm speechless, don't even know what to say here.

I'm appealing here, please suspend and reevaluate the steps being taken. This way both Chrome Extensions and Chrome WebStore will be killed.

Chrome need Devs, and Devs need Chrome. This way it is not going to work. 

We are seeing to a battlefield between Chrome and Devs and there are no winners in this war.

Please look at Android, they never went this route. Android upgraded it's SDK, always bringing new and exciting and more powerful features.

I don't understand why Chrome is killing and crippling the platform. Instead of better features, they are being cut out. And MV2 and MV3 is not compatible at all. At Android despite the evolution the compatibility was always guaranteed. On Chrome there is no compatibility between MV2 and MV3 because the most important things on extension are cut out from Extensions API. 

Also MV2 will be cut out from Chrome WebStore forcing for worse extensions on MV3.

Please reevaluate the steps. Listen to the Devs and go the Android way. 

This is my testimony, and again, I'm appealing: please suspend this nightmare.

Greetings :)

[wOxxOm]

Google cares about Android and its developers because Android and the related services make huge money. Extensions, on the other hand, is a dead weight. The paid extensions revenue is negligible as you can see in a recently published analysis (I don't have the link, sorry).

Over the last five years there was only one Chromium developer (Devlin Cronin) who maintained the extensions component, fixed the bugs and reviewed the related code by other developers day-in day-out. Other Chromium developers only occasionally work on the extensions component (when their main task involves some related changes). If you inspect the bug tracker https://crbug.com you will see hundreds of ignored/abandoned/postponed extension-related bug reports and feature requests accumulated over the last ten years. The public extensions API is essentially frozen, only a few trivial methods were added.

So what really happens, I think, is that Chromium team has finally realized that Google doesn't care about extensions, that there won't be any increased task force, so the team tries to survive by reworking the API in a way that's easier for them to maintain in the long run.

[Aleksandr G.]

On Friday, November 15, 2019 at 5:32:35 PM UTC+2, PhistucK wrote:

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.

Yes, I completely understand this initially before posting my question. But at least Chrome developers should allow the same way of registering Service Workers as with Content Scripts - array of any required script specified in the manifest, and such solution will allow to use any script either as content or as service worker excluding code duplicating. Don't you think that writing thousands lines of code if couple places (even in 2 of them) is not a great idea? Support of such code is completely hell as it requires fixes in couple places instead of one.

[PhistucK]

It was not clear, then, sorry.

(Service) workers can import scripts using importScripts/dynamic import (I think regular module import statements are being considered as well).

Why do you need to define it in manifest.json instead of in the file?

You cannot avoid the duplication anyway (once for content scripts and once for the service worker).

☆PhistucK

--
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.

[PhistucK]

A reference for regular module import statements - 

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABj5diMPoV8ep6rue%3DVnGdTubRd4v2bpaWGxX8GT9GkRbZWNVg%40mail.gmail.com?utm_medium=email&utm_source=footer

Maybe it is worth it to apply it to background service workers of extensions out of the box.

☆PhistucK

[wOxxOm]

• https://crbug.com/824647 tracking bug for ES Modules in service workers
• https://crbug.com/1020812 Clarification request for ManifestV3 extensions support of the above
  

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[Panja]

Sincerely thank you Simeon - @dotproto for the update. 

I have been exercising the migration to the MV3 according to the migration guide. However, I have a specific use case that I do not know how to achieve it with the declarativeNetRequest. Please help.

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?

Thank you in advance,

Panja

[Vassilis Androutsopoulos]

I have made an extension to block responses (not requests) based on "content-type" header, using webRequest.onHeadersReceived API.

I'm using my extension in a school LAN to block whole mime types, like videos and images.

Will I be able to do the same with manifest v3?

[Anton Bershanskiy]

In Manifest V3 webRequest API is replaced with declarativeNetRequest API. It does not expose raw headers like Content-Type, but you can write rules based on ResourceType which is inferred from it. Types "image" and "media" are probably the most useful ones.

On a side note, blocking whole MIME types is very draconian and not at all effective and just encourages students to circumvent whatever measures you put in place. On the other hand, I bet anyone who wanted to already found a way to bypass this extension anyway.

[John]

Thanks for the response! I'll check ResourceType. And I'm talking about kids from a primary school (ages 6-11) who are not allowed to view videos and who don't know how to bypass my extension :-)

[Aleksandr G.]

(Service) workers can import scripts using importScripts/dynamic import (I think regular module import statements are being considered as well)

Thank you so much! importScripts() solved my problem. Didn't know about that API.

At the moment only one issue left which I already mentioned:

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!!!

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.

Is there any ticket for this issue in the Chrome bug tracker? Can't find anything similar.

P.S. I'm using Chromium build as the most fresh for testing V3.

[Aleksandr G.]

Just created new ticket in the bug-tracker for "Native Messaging Host kept running by Service Worker after its destruction" issue I reported above.

https://bugs.chromium.org/p/chromium/issues/detail?id=1030305

[Kent Brewster]

> On Nov 18, 2019, at 12:52 AM, PhistucK <phis...@gmail.com> wrote:
>
> (Service) workers can import scripts using importScripts/dynamic import (I think regular module import statements are being considered as well).

Is there a tracking bug for regular module imports? Will we be able to use them in content scripts as well as service workers?

I think this may turn out to be very important in the future. If we can ship modules in a filesystem and not a bunch of Webpack-built artifacts, reviewers will have an easier time understanding at the code.

--Kent

[PhistucK]

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

[Anton Bershanskiy]

> If we can ship modules in a filesystem and not a bunch of Webpack-built artifacts, reviewers will have an easier time understanding at the code.

As far as I know, no one does any routine manual reviews for CWS: they are completely automated. The only time when CWS reviews code manually is when someone complained or something flagged an extension for a manual review. Firefox does some manual reviews, but only for extensions with "dangerous" permissions like very powerful permissions or lax CSP allowing remote code.

However, modules might indeed improve performance, if extension can load dependencies only when they are needed.

[Kent Brewster]

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

[PhistucK]

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.

(I have a @chromium.org e-mail, but I am not a Googler)

☆PhistucK

[Simeon Vincent]

Hey, another "Simeon took too long to check in on this thread and now there are a ton of things he needs to reply to" post!

Are you required to switch to service worker (non-persistent) background pages if you need to continue using non-blocking webRequest?

-Alex 

Yes. Background pages are being replaced with service workers and all extensions must migrate to service workers in order to be compatible with Manifest V3.

What's the mechanism for learning what declarativeNetRequest did (which requests were blocked/redirected) on a given tab?

-Alex 

The extensions team is actively working on a reporting API that provides asynchronous reporting on rule matches. With luck we'll be sharing more on this later this month or in Q1 2020

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

Sandboxed pages will continue to exist; they are not being replaced by workers. At the moment the default CSP for sandboxed pages allows unsafe-eval. To my knowledge we plan to continue to allow sandboxed pages to eval, but this should not be taken as a guarantee that eval will be allowed in sandboxed pages. If this is a capability you're interested in using, please share more about your use case for future discussions on this.

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.

I'll go ahead and say that's my bad. Still is. I've been meaning to push a couple bug fixes and updates to the docs, but I broke my Chromium environment and haven't had a chance to fix it yet.  I should also call out that we're planning to address the DX issues here, they're just lower priority than making the MV3 platform work in the first place. 

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.

A member of the extensions team checked in a fix for that late last week. Just checked in with the committer and they mentioned that they're adding additional tests to ensure this feature works as expected. If it doesn't work in Canary now, it should in the next few days.

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

Hm. I have an idea on how to handle this, but it's not too pretty. For forms, you can inject a content script at document_start and register a capturing event listener on document that performs your validation synchronously in the page and calls event.preventDefault and event.stopPropagation to cancel the request before it can reach application code if it shouldn't go through. Similarly, you can inject a script into the host document to override fetch() and XMLHttpRequest for the page in order to intercept POST requests and execute your validation logic. I suspect this would be able to achieve comparable results.

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.

The multiple native messaging clients is definitely a bug in Chromium. Thanks for filing a bug report. 

As for the action icon blinking, that's most likely an artifact of the way the service worker initialization script is currently structured. I suspect the the extension currently has some logic to set the icon to a "not ready" state when the script is first invoked, then once the native client connection is established asynchronously the extension switches the icon to a "ready" state. The solve that jumps to mind right off the bat is to add a short debounce timer to your initial icon state. Rather than set it immediately, wait 100 ms (or other appropriate duration). If the native client connection is established before the debounce timer limit is reached, cancel the icon update. If that's not a good fit for your use case, I'd be happy to kick around other ideas.

As far as I know, no one does any routine manual reviews for CWS: they are completely automated

- Anton Bershanskiy

We use a combination of automated and manual review. While I can't go into detail here, I think it’s safe to say that humans are more involved than you suspect ;)

Cheers,

Simeon - @dotproto

Extensions Developer Advocate

On Tuesday, December 3, 2019 at 1:35:55 PM UTC-8, PhistucK wrote:

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.

(I have a @chromium.org e-mail, but I am not 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:

[Jack Works]

In our extension, we need to:

- Access the DOMParser to parse HTML

- Inject content script by chrome.tabs.executeScript instead of using manifest cause we need to support runtime permission.

- Run a long-time connection to receive messages from the internet.

The ServiceWorker model doesn't work for us because there is no way to wake up our extension backend.

We cannot use server push or other techniques to wake up the Service Worker because we're a decentralized app, therefore no server.

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 expect

We'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 guide

In 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,

[馮韋元Francois Devatine]

A lot of people are currently working on updating their extensions to be compliant with the recent chrome policy update https://blog.chromium.org/2020/04/keeping-spam-off-chrome-web-store.html

We also have to keep in mind the migration to manifest V3 coming up at some point in the future.

A lot of people are very confused with the fact that extensions can not have duplicates in the store after the new chrome policy. It will obviously be a problem when we switch to Manifest v3.

How will we roll out the extension? How will we migrate users? Will we able to have duplicates for this case?

Thanks