New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebExt: Support all GM APIs #2484
Comments
bug1323433 and bug1332273 may be of interest here. |
Thanks for the pointers, I agree those are both super useful. |
Oh, maybe some amount of synchronous message passing is possible! Test this. Does this make it possible to use a simple synchronous implementation (backed by background-only APIs) for those methods called out above? |
That returns a promise on the content side, so it is effectively async. i think "synchronous" is a misnomer here, it's more like pairing a message from child to parent with a response so that one does not have to manually keep track of pending responses. Afaik the only synchronous API available are sync XHRs which then could be intercepted with webrequest or something like that. |
Sync XHR not work properly in content script: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, so at now we don't have any sync channel from content > background. Looks like Regardless how you solve the above issues in WebExt version we should get new set/get method designed in async manner, so where it's important we can write the script in a async way. Documentations should have some information about lack |
imo, it is rare use cases that using btw, if so, add an API equivalent to |
In my dev branch there is support for:
I plan to never add:
We still need:
I plan to delay (or maybe drop):
Which means progress here is actually quite close. |
Good feedback at above commit, don't forget. |
I just have a try on the new add-on. It seems that cross domain xhr request had already been enabled without GM_xhr features. Is this indeed behavior? Just try a userscript grant none with following codes: fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error)); |
Ugh, confirmed. We're currently executing user scripts as "content scripts" -- of the extension, with all the extension's permissions. |
I've looked into this a bit but so far I'm in the dark as to how to execute unprivileged ("web scope" -- what do we call this now that "content" scope is ambiguous?!) code. The closest thing I can find is all about creating script tags, which can/will be blocked by the page's CSP, which I definitely don't want. |
Currently the only way to modify CSP is intercepting and modifying the headers for every Document request. There are open issues to exempt webextensions from content CSPs but there doesn't seem to be much activity on those. Besides injecting The official terms are "content script scope" vs. "page scope". Another issue is that they would need string-processing to wrap them in a separate scope that could define the GM APIs. I have also filed a bug for |
AIUI both script and eval are vulnerable to blockage by CSP. But I have confirmed that eval drops privileges. |
https://bugzilla.mozilla.org/show_bug.cgi?id=1391669 We must have At least in Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval()_in_content_scripts ) we can drop down to page scope, but then we're truly page scope and we can't safely expose APIs to the script without exposing it to anything/everything running in the page (AFAIK), which is even worse. |
Can fetch and xhr be overwritten in the content script? |
|
@the8472 See my implementation of It mimics the behavior of the old |
These were denoted in the creation of this ticket (by @arantius on Mar 3) as trivial (assuming a mapping of GM_log to console.log). In my experience, these are two of the most commonly used API calls. Wouldn't abandoning them break a lot of old scripts for no reason? Or were you exclusively referring to the dev branch? |
In Tampermonkey, |
https://wiki.greasespot.net/Greasemonkey_Manual:API
The Greasemonkey APIs are generally privileged actions, and generally all synchronous actions. Content scripts have (almost) no API access, and thus must pass messages to perform privileged actions. Web extensions only get asynchronous message passing (citation needed).
So each method has its own challenges.
Easier:
GM_getResourceURL
must produce a result synchronously, but is trivial to calculate.GM_addStyle
is trivial.GM_log
should probably be retired, or just mapped toconsole.log
.GM_openInTab
functionally produces no result, even ordering is not critical.GM_registerMenuCommand
has no synchronous behaviors.GM_setClipboard
produces no result.GM_xmlhttpRequest
is fully asynchronous.Harder:
GM_deleteValue
produces no result. Ordering still matters (i.e. delete of X must happen before any future set of X).GM_setValue
is equivalent to delete. No synchronous result, but ordering matters.Very hard:
GM_getValue
must produce a result synchronously.GM_listValues
must produce a result synchronously. (Plus AFAICT storage gives no good backing API. The only option is to fetch one value by name, or fetch all names and values. With no way to even segregate e.g. by script.)GM_getResourceText
must produce a result synchronously, and they may be very large values. (I.e. pre-caching them all in memory is likely too expensive.)The text was updated successfully, but these errors were encountered: