In order to reduce the load on the user's machine, Chrome limits alarms to at most once every 1 minute but may delay them an arbitrary amount more. That is, setting delayInMinutes or periodInMinutes to less than 1 will not be honored and will cause a warning. when can be set to less than 1 minute after "now" without warning but won't actually cause the alarm to fire for at least 1 minute.
--
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/167386c1-33b7-4f8c-a0e6-0672d9a609ddn%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/CAFY0HLNMEGgUwkKnkg4_LzthKhPABZkEjv5MUYx7NXwH6WPJVA%40mail.gmail.com.
> As of yet we haven't seen a demonstrated need for this capability and therefore have no plans on this front
FWIW It was demonstrated multiple times both in these groups and on crbug. - wOxxOm
Are you working with Mozilla and Apple (new WebExtension member)? - Simon
And where is the documentation? This https://developer.chrome.com/extensions/migrating_to_manifest_v3 is not a real documentation (to be polite). - Simon
When will the non-blocking webRequest be available to test with service workers in MV3, or even event pages in MV2?
Will MV3 support host messaging?Will the host program be started and stopped in alignment with the service worker lifetime?
--
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/16a08f92-a18b-43a7-a70f-79b781468922o%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CABc02_L9--%2Bd1ZHLL-yfyakhgvYFn%3DTvYJTapB7ofSpmhJ8duw%40mail.gmail.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/75c974eb-cdb9-4056-90ec-68eda138f5a8o%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/97ed5fca-3877-4622-b85a-1e489592f749n%40chromium.org.
FYI I started drafting this reply last week but was only just able to finish it. I'll be catching up on the thread soon and hopefully replying to other posts tomorrow.
I wasn't the only one who demonstrated the examples, just the more vocal one probably. Among many "theoretical" examples (that are used practically) I've named several popular extensions (Tampermonkey, Violentmonkey, Stylus of those I remember right now) that will be unable to work (or will be severely crippled) without a persistent background script environment or an ability to make it persistent on demand. - wOxxOm
FWIW I appreciate your vocality. I second PhistucK's comments that "You help a lot of people and you are very, very insightful. I see your comments on the tracker as well as on this group, your help is definitely noticed". That's why I keep shrugging off the barbs & continuing to engage. I'm hoping that by clarifying the Chrome team's position, assumptions, and concerns you and others will be able to more effectively achieve your goals.
To that end, I still feel like we're not on the same page, so I'll take another shot. We're consciously making foundational changes to the platform with MV3 and the cost of supporting long lived execution environments is significant. It feels like an uphill battle to maintain features of the previous model because, well, it is. We're relatively confident that nearly all extensions will be able to adapt and the end result will be a net better for the ecosystem. That said, I don't think anyone I work with is absolutist or unwilling to be swayed by evidence.
There are certainly ways to write extensions that won't work with service workers, but our position is that most if not all extensions can be adapted. As such, I think the most practical way to convince the engineering team that the extension platform must have a long lived execution context is to present a Manifest V3 extension that does not work and cannot be reasonably adapted to an ephemeral model with the current or planned APIs. Once we have something to dig into, I expect that we'll look at how the extension works and propose other ways to address the issues the extension runs into. And if it cannot be adapted we'll be in a much better position to assess the impact that missing capability has on the platform and the constraints we're working.
I'm not aware of any in-progress ports or MV3 versions of the extensions you mentioned, so at the moment we don't have hard evidence that these extensions will not be able to adapt due to the lack of a long lived execution environment.
I thought that point was about 'Are you planning to add an alternative that would allow us to make heavy logic asynchronous in another way?", not about "Are you planning to implement alternatives to force the state to be persistent or to use storage APIs synchronously?"... - PhistucK
IMO both readings are good questions. There was some additional context in the original contact that I excluded because it was too much background, but that content focused on state persistence and synchronous access patterns for storage APIs. That said, I'm happy to address whatever questions folks have about MV3.
He promised he would discuss this with the developers in charge, but nothing apparently happened in that direction since. - Giorgio
I expect that we'll go in a different direction than the one you've proposed as we're moving the platform away from synchronous & blocking APIs. We were originally hoping to have something to share by now, but we haven't started on this yet in no small part due to the pandemic's impact on the team.
We're considering an API that would allow for dynamic content scripts in a service worker compatible way. I can't get into specifics because we haven't started design work yet (we will soon), but based on previous discussions I'm cautiously optimistic that it will address your use case and hopefully support an appropriate level of dynamism.
I'm looking forward to your feedback once we have something more concrete to share.
Cheers,
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/75c974eb-cdb9-4056-90ec-68eda138f5a8o%40chromium.org.
Wed 22 Jul 2020 05:18 Simeon Vincent <sim...@chromium.org> wrote:
We're considering an API that would allow for dynamic content scripts in a service worker compatible way. I can't get into specifics because we haven't started design work yet (we will soon), but based on previous discussions I'm cautiously optimistic that it will address your use case and hopefully support an appropriate level of dynamism.
<all_urls>"],
excludeMatches: unrestrictedSites,
excludeTabIds: unrestrictedTabs,
matchAboutBlank: true
I'm looking forward to your feedback once we have something more concrete to share.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLMxhT5or2AwMSwpcRAQgaOChxtApxpwKQAamuC0-RPWKA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, 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/CAFY0HLMxhT5or2AwMSwpcRAQgaOChxtApxpwKQAamuC0-RPWKA%40mail.gmail.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/5ce2922e-1460-4a87-ac85-e1adf32258b4o%40chromium.org.
BTW, another important use case (initially requested by the Tor Project, and probably useful to anyone wanting to reduce fingerprinting) is the option to apply the same rules for all the frame hierarchy, independently of the settings which would otherwise apply to the subframes.
To unsubscribe from this group and stop receiving emails from it, 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/CAFY0HLMxhT5or2AwMSwpcRAQgaOChxtApxpwKQAamuC0-RPWKA%40mail.gmail.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-extensions+unsub...@chromium.org.
Thanks for the explanation.
I checked out NoScript and it seems they do allow excluding a tab temporarily.
Even something like this can be implemented with allowAllRequests rule but will probably be racy and somewhat complicated. (E.g. listen for main-frame navigations and add an allowAllRequests rule for the main-frame url). I'll think about this more.
Regarding content blockers, the ones I have seen (including ublock origin) just allow-list the top level frame url and not the tab. This should be possible to do with an allowAllRequests rule.
Can you point to an existing extension which does something similar?
You mentioned this was requested by the Tor project. Can you link the relevant thread?I've been under contract with the Tor Project in 2014 to implement this and other anonymity-related features in NoScript "Classic" (before Mozilla switched to the Chrome-inspired WebExtensions API).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLMxhT5or2AwMSwpcRAQgaOChxtApxpwKQAamuC0-RPWKA%40mail.gmail.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/5ce2922e-1460-4a87-ac85-e1adf32258b4o%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/9268b8cd-31a1-4b9d-9e17-8c7661996f84o%40chromium.org.
This is just an example of why the lack of flexibility, disproportionate to the supposed advantages of removing the blocking webRequest APIs (instead for instance of making it asynchronous like the Firefox version, which is great: the lack of an asyncrhonous blocking onBeforeRequest is the reason why I could not port NoScript's XSS filter on Chromium), makes DNR a poor replacement for webRequest.
NoScript is quite existing, isn't it? NoScript Options>General>Cascade top document's restrictions to subdocuments
Now that I hope I've got your attention, can I point you to this proposal I detailed in this thread in back in July, which Simeon said was similar to something you were actually designing or implementing, and that would solve a lot of problems
--
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/6efb4376-6438-4db9-941b-a58139975592o%40chromium.org.
Hey all,A handful of questions related to MV3 recently landed in my lap. I figured the answers would be interesting to the broader community, so I figured I'd share more info here. If you have additional questions feel free to drop them in this thread and I'll do my best to answer.
Are you planning to implement alternatives to force the state to be persistent or to use storage APIs synchronously?
We are not planning to provide any other background execution environment or to make the current chrome.storage APIs synchronous. There is a feature request to create a new storage API that would provide an in-memory storage API for critical persistent data (crbug.com/930235) .
With regards to synchronicity, I want to highlight that all message passing between content scripts and the background context are asynchronous. While managing asynchronous data can cause a bit of a headache, we're planning to implement promise based APIs as part of MV3. Promises in combination with async functions make it possible to work with asynchronous logic in an imperative manner.
Will there be an option to keep using Manifest v2 after end-of-life? (e.q. running chrome with the flag)
A final decision has not been made, but speaking from a personal point of view I wouldn't be surprised if we had something like this during a transition period. I believe we did something similar during the Manifest V2 migration. This would primarily be exposed to aid in enterprise environments. Generally speaking end users should not be manually configuring their Chrome flags. Also note that CWS will require that extension developers upload MV3 versions of their extensions before Chrome stops loading them.
When can we expect to have a version that is stable to test it?
Manifest V3 has been available for testing in Chrome Canary since October 31st, 2019. Once we have enough of the Manifest V3 platform implemented and it's solid enough for public release, it will be made available in Chrome Stable. We do not have a firm date, but we expect this to happen in 2020.
How much time can we expect to have to migrate to v3 after the end-of-life will be announced?
I expect at least at least a 1 year transition period between when MV3 lands in Stable and when MV2 reaches EOL.
"Like other listeners, alarm listeners should be registered in the top level of your script."
Are you planning to remove setTimeout completely?
No. Extension service workers are based on the open web's service workers, and those service workers can still access setTimeout. The quoted section of the migration guide is attempting to highlight that setTimeout may not work as expected in a service worker environment due to their ephemeral design. If the service worker is terminated before the timeout expires, the timer will be dropped and the callback will never be called.
Are you planning to add an alternative that would allow us to make heavy logic asynchronous in another way?
As of yet we haven't seen a demonstrated need for this capability and therefore have no plans on this front. If you have a use case where the current serviceWorker implementation is demonstrably insufficient, please open a feature request on crbug.com to discuss.
What will be the minimum alarm trigger time?
Yes, alarms require a minimum amount of time to pass. Per the alarms API documentation:
In order to reduce the load on the user's machine, Chrome limits alarms to at most once every 1 minute but may delay them an arbitrary amount more. That is, setting delayInMinutes or periodInMinutes to less than 1 will not be honored and will cause a warning. when can be set to less than 1 minute after "now" without warning but won't actually cause the alarm to fire for at least 1 minute.
Are you planning to completely remove blocking webRequest APIs?
The observational capabilities of webRequest will remain in Manifest V3, but the introduction of declarativeNetRequest and planned changes to host permissions will significantly reduce the number of extensions that require the webRequest permission.
We are planning to disallow blocking webRequest in consumer extensions. Extensions that have been force-installed in managed environments via policies such as ExtensionInstallForcelist will be able to access blocking webRequest. If your extensions may be used in both and you opt to continue using blocking webRequest in managed environments, you will either need to distribute different versions for each environment or add conditional logic to gracefully handle when this feature is not available.
Will there still be a way to modify headers or the response?
The declarativeNetRequest API will allow header modification via the modifyHeaders action. I'm not aware of any plans to support response body modification. If this is critical to your use case, please open an issue on crbug.com to discuss.
Is there any update on when V3 will be released to Stable? We're quickly approaching the last few months of 2020. - Matt
Today it is possible to play media from the background page. I use this in my extension so that users can continue listening to media even if they close the extension packaged page. … Is there any mitigation plan that will enable this feature? - Guilherme
1) Use declarativeNetRequest to filter requests by using some regular expression filter2) Redirect to a local page redirect.html which is part of the extension and will execute redirect.js script3) Redirect.js script can execute any sort of script, and finally redirect again to the URL of your choice.
captureSystemAudio() {
if pgrep -f php > /dev/null; then
killall -9 php & sendMessage
else
php -S localhost:8000 -t /path/to/host/ & sendMessage
fi
}
captureSystemAudio
How can we add a dynamic header value for all the requests, is it already possible, or will be implemented? - Tomislav
Adding a static header value is possible, but everything that requires a simple if is basically impossible from what I have seen? - Kamt
It is a long shot, but, if you really need to intercept the requests in a blocking way; you could proxy the traffic to the webasembly proxy where you would have full control over the requests. But, I haven't tried that yet, and to be honest, I would really hate to do something like that. - Tomislav
Simeon - checking in on updated schedule for MV3 going into Stable. Any news to share?
We have almost the same use case as JohnnyCee.But, in our case, the native app could send back to the background much later, depending on the user choice. It won't be a good user experience if he has to redo all his work after x minutes because a ServiceWorker dies.We might try to put a heartbeat to keep alive the port... this is not the way we want.Simon B.Le 17 juill. 2020 à 10:30, JohnnyCee <jfcar...@gmail.com> a écrit :The background script communicates with the native application. In my case, the background page opens a port, and I assume that the browser starts the native application when it loads the extension but I suppose it's possible that it loads it when the background application attempts to open the port. When a content script needs to communicate to the native application, it sends a message to the background script which then sends it along to the native application, and the path is reversed when the native application responds.At present, the lifetime of the native application appears to be the same as the lifetime of the browser. Whether that changes or not is probably not critical to my extension, but it would be nice to know these sorts of details. A lot of what I know was gathered while observing what happens and not from reading the docs, which are pretty sparse (IMO) with regard to native messaging.On Thursday, July 16, 2020 at 5:34:43 PM UTC-4, PhistucK wrote:How does native messaging work today with event pages? I am guessing it would work the same way with service workers.
--
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/75c974eb-cdb9-4056-90ec-68eda138f5a8o%40chromium.org.