Chrome: use declarativeNetRequestWithHostAccess instead of webRequestBlocking

[WorldLanguages]

EDIT: outdated

The new declarativeNetRequestWithHostAccess permission will ship in Chrome stable on November 16 2021.
Around three months later (February 2022), we'll remove the webRequestBlocking permission from our Chrome manifest.json and start using declarativeNetRequestWithHostAccess instead.
Users running Chrome 95 and below will still be able to use Scratch Addons by then, except some scratch-messaging and scratch-notifier features (more detail below).
Firefox will continue to use webRequestBlocking, possibly forever.

We currently use blocking webRequest for:

• Fetching ?sareferer URLs (used to delete/post comments and clear message count from background/popup contexts)
• Removing Set-Cookie headers from https://scratch.mit.edu/site-api/comments/* responses which unexpectedly log users out. Removed in v1.24.3 through Remove unnecessary background/handle-cookie.js #4237 and no bug reports received about unexpected logouts yet.

Moving away from webRequestBlocking is a good first step to be ready for manifest v3, and may also possibly speed up our Chrome Web Store review times.

[cobaltt7]

Users running Chrome 95 and below will still be able to use Scratch Addons by then, except some scratch-messaging and scratch-notifier features (more detail below).

where :thonk:

[CST1229]

Users running Chrome 95 and below will still be able to use Scratch Addons by then, except some scratch-messaging and scratch-notifier features (more detail below).

where :thonk:

• Fetching ?sareferer URLs (used to delete/post comments and clear message count from background/popup contexts)
• Removing Set-Cookie headers from https://scratch.mit.edu/site-api/comments/* responses which unexpectedly log users out. (added by quoter: this means profile comments won't log the user out)

[WorldLanguages]

(added by quoter: this probably means that profile comments won't work)

No, they'll still work. All we did to those URLs is prevent them from logging the user out.
URL param sareferer is used for:

• Marking messages as read (scratch messaging and notifier)
• Posting comments, deleting comments, clearing alerts (scratch messaging)

[cobaltt7]

Maybe we can change webRequestBlocking to an optional permission and only request it if declarativeNetRequestWithHostAccess isn't supported

…

________________________________ From: World_Languages ***@***.***> Sent: Wednesday, October 6, 2021 5:53:23 PM To: ScratchAddons/ScratchAddons ***@***.***> Cc: Subscribed ***@***.***> Subject: [ScratchAddons/ScratchAddons] Chrome: use declarativeNetRequestWithHostAccess instead of webRequestBlocking (#3615) The new declarativeNetRequestWithHostAccess permission will ship in Chrome stable on November 16 2021. Around three months later (February 2022), we'll remove the webRequestBlocking permission from our Chrome manifest.json and start using declarativeNetRequestWithHostAccess instead. Users running Chrome 95 and below will still be able to use Scratch Addons by then, except some scratch-messaging and scratch-notifier features (more detail below). Firefox will continue to use webRequestBlocking, possibly forever. We currently use blocking webRequest for: * Fetching ?sareferer URLs (used to delete/post comments and clear message count from background/popup contexts) * Removing Set-Cookie headers from https://scratch.mit.edu/site-api/comments/* responses which unexpectedly log users out. Moving away from webRequestBlocking is a good first step to be ready for manifest v3, and may also possibly speed up our Chrome Web Store review times. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#3615>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOT5DERQLAVEDLZOREWOAK3UFTHOHANCNFSM5FP5RRRA>.

[WorldLanguages]

webRequestBlocking does not have any "permission warnings" so there's no real difference in the review process between making it required or optional.

[WorldLanguages]

Update: because of #3625 removing Set-Cookie is no longer necessary. AFAIK it was added because of scratch-messaging automatically logging users off, and that can't be the case anymore. We could still keep it, but there's no real reason to do so.

[WorldLanguages]

I forgot to mention, by removing webRequestBlocking we could convert our background page to non-persistent, as a first step into having a service worker background.
The only reason it's persistent is because it's required for webRequestBlocking.
We should make sure we don't have any left over code (specially chrome.contextMenus) that wouldn't work in a non persistent background page.