Some basic questions about the new Manifest v3

[Sumeet Agrawal]

I've read some of the discussions and also read about the upcoming changes for Chrome extensions Manifest v3.

A few changes that might affect us:

1. Discarding of background pages
2. Use of DeclarativeNetRequest API instead of WebRequest API

I am little bit confused and would really appreciate if someone could help me understand this: 

1. If Chrome is going to deprecate the background pages, then where exactly are we going to write the code for our extensions? E.g., we'll write the code in 'script.js' and refer to this script from our extension manifest file?
2. How is the 'Native Host Process communication' with extensions going to work with the new 'DeclarativeNetRequest API'? Same as before?
3. I read the documentation https://developers.chrome.com/extensions/declarativeNetRequest and it is mentioned there that "the declarativeNetRequest API is given priority over the webRequest API because it allows for synchronous interception". So, for e.g., is it going to be possible for me to intercept an HTTPS request from Chrome, make it wait, for say a max of 10 seconds, during which I'll pass the details of the request to the Native Messaging Host process, that Native Process will perform certain computations and then return a final verdict - Block or Allow. And then based on this verdict, the NetRequest will be Blocked or Allowed. Will this be possible? 
4. The methods being offered right now from https://developers.chrome.com/extensions/declarativeNetRequest are just for adding or removing rules but there is no information about methods that we'd be able to use for obtaining details about the request headers / request data. Am I missing something or those methods are still under development?       
5. API available from https://developers.chrome.com/extensions/declarativeNetRequest  is said to "Not fully implemented. You must build Chromium from source to try this API." But I've seen from Google Groups discussions that the Developers will be given time to adapt their code from v2 to v3. Approximately by when will we get this API in release builds?

[Sumeet Agrawal]

Can anyone please help?

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a2ea1d82-d5e3-463b-b4c4-0d47ff52f11e%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--

sums(sumeet agrawal)
slg....@gmail.com

[Simeon Vincent]

1. If Chrome is going to deprecate the background pages, then where exactly are we going to write the code for our extensions? E.g., we'll write the code in 'script.js' and refer to this script from our extension manifest file?

Background pages are being replaced by service workers. The extensions team is actively working on the service worker implementation, so we don't have a final name for the service worker entry point in manifest.json. That said, the current implementation would look like this:

// Current manifest entry
"background": {
  "scripts": ["background-script.js"]
}

// Future (maybe???)
"background": {
  "service_worker": "background-sw.js"
}

2. How is the 'Native Host Process communication' with extensions going to work with the new 'DeclarativeNetRequest API'? Same as before?

To my knowledge native host messaging should work as it does today in persistent background pages. I'm not sure how declaritiveNetRequest (DNR) would be involved, though. Is there something specific that you're concerned about here?

3. I read the documentation https://developers.chrome.com/extensions/declarativeNetRequest and it is mentioned there that "the declarativeNetRequest API is given priority over the webRequest API because it allows for synchronous interception" … Will this be possible? 

No, the scenario you described will not be possible.

A key aspect of this API is that its declarative. Unlike blocking webRequest, you will not be able to intercept and block a request. Rather, with this API you define a set of rules and actions to take if those rules are matched, and then  hand them off to Chrome for execution. For example, you could create a rule that says something like "if the request has a cookie named 'tracking_*', remove the cookie from the request".

4. The methods being offered right now from https://developers.chrome.com/extensions/declarativeNetRequest are just for adding or removing rules but there is no information about methods that we'd be able to use for obtaining details about the request headers / request data. Am I missing something or those methods are still under development?

You're correct. DNR is not meant as a complete replacement for the webRequest API. Only the blocking capabilities of the webRequest API are deprecated; the observational capabilities will remain. You will still be able to use webRequest to inspect requests but you won't be able to use this API to modify them in flight. 

5. API available from https://developers.chrome.com/extensions/declarativeNetRequest  is said to "Not fully implemented. You must build Chromium from source to try this API." But I've seen from Google Groups discussions that the Developers will be given time to adapt their code from v2 to v3. Approximately by when will we get this API in release builds?

That note in the DNR API docs ("You must build Chromium from source to try this API") is not completely accurate. Some DNR capabilities are in stable now. That said, this API is still very much a work in progress. I'd recommend using Chrome Canary to experiment with it and let us know what issues you run into.

Simeon - @dotproto

Extensions Developer Advocate

On Friday, May 10, 2019 at 2:37:46 AM UTC-7, Sumeet Agrawal wrote:

Can anyone please help?

On Mon, 6 May 2019 at 17:23, Sumeet Agrawal wrote:

I've read some of the discussions and also read about the upcoming changes for Chrome extensions Manifest v3.

A few changes that might affect us:

1. Discarding of background pages
2. Use of DeclarativeNetRequest API instead of WebRequest API

I am little bit confused and would really appreciate if someone could help me understand this: 

1. If Chrome is going to deprecate the background pages, then where exactly are we going to write the code for our extensions? E.g., we'll write the code in 'script.js' and refer to this script from our extension manifest file?
2. How is the 'Native Host Process communication' with extensions going to work with the new 'DeclarativeNetRequest API'? Same as before?
3. I read the documentation https://developers.chrome.com/extensions/declarativeNetRequest and it is mentioned there that "the declarativeNetRequest API is given priority over the webRequest API because it allows for synchronous interception". So, for e.g., is it going to be possible for me to intercept an HTTPS request from Chrome, make it wait, for say a max of 10 seconds, during which I'll pass the details of the request to the Native Messaging Host process, that Native Process will perform certain computations and then return a final verdict - Block or Allow. And then based on this verdict, the NetRequest will be Blocked or Allowed. Will this be possible? 
4. The methods being offered right now from https://developers.chrome.com/extensions/declarativeNetRequest are just for adding or removing rules but there is no information about methods that we'd be able to use for obtaining details about the request headers / request data. Am I missing something or those methods are still under development?       
5. API available from https://developers.chrome.com/extensions/declarativeNetRequest  is said to "Not fully implemented. You must build Chromium from source to try this API." But I've seen from Google Groups discussions that the Developers will be given time to adapt their code from v2 to v3. Approximately by when will we get this API in release builds?

sums(sumeet agrawal)

[Sumeet Agrawal]

Thanks a lot Simeon for answering all my questions.

For now, I just have 1 more query: 

You mentioned: A key aspect of this API is that its declarative. Unlike blocking webRequest, you will not be able to intercept and block a request. Rather, with this API you define a set of rules and actions to take if those rules are matched, and then  hand them off to Chrome for execution. For example, you could create a rule that says something like "if the request has a cookie named 'tracking_*', remove the cookie from the request".

As I understand it, we will have to define such rules in a separate rules.json file which we will mention in the extension manifest file. And this rules file can (currently) contain 30k rules at max. Is this understanding correct?

If it is, then would it also be possible to modify this rules.json file at any time and these rules will be effective immediately even if Chrome is already running?

--

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/4f7a5989-2795-41da-8442-8c159932f608%40chromium.org.

--

sums(sumeet agrawal)
slg....@gmail.com

[Simeon Vincent]

The extensions team is expecting most extensions to use declarative_net_request.rule_resources to set most of their rules and to use the addDynamicRules/removeDynamicRules APIs to modify rules at runtime. Static and dynamic rules are (currently) separate lists. The maximum rule count applies to the combined total of both of these lists. The static JS rules (the rules.json you mentioned) is a included with your extension. As such, it's not possible for the extension to modify the contents of these files.

Regarding the 30k limit, we're planning to raise it. In Iterating on Manifest V3, Devlin mentioned that "we will raise the rule limit from the draft 30K value". We don't have a final number for the limit as we still need to do performance testing to determine how high we can go. 

Hope that helps!

Simeon - @dotproto

Extensions Developer Advocate

On Monday, May 13, 2019 at 10:51:58 PM UTC-7, Sumeet Agrawal wrote:

Thanks a lot Simeon for answering all my questions.

For now, I just have 1 more query: 

You mentioned: A key aspect of this API is that its declarative. Unlike blocking webRequest, you will not be able to intercept and block a request. Rather, with this API you define a set of rules and actions to take if those rules are matched, and then  hand them off to Chrome for execution. For example, you could create a rule that says something like "if the request has a cookie named 'tracking_*', remove the cookie from the request".

As I understand it, we will have to define such rules in a separate rules.json file which we will mention in the extension manifest file. And this rules file can (currently) contain 30k rules at max. Is this understanding correct?

If it is, then would it also be possible to modify this rules.json file at any time and these rules will be effective immediately even if Chrome is already running?

sums(sumeet agrawal)