Extensions content scripts do not have access to Secure Context APIs in HTTP sites like getCoalescedEvents
Categories
(WebExtensions :: General, defect, P3)
Tracking
(firefox121 unaffected, firefox122 unaffected, firefox123 verified)
Tracking | Status | |
---|---|---|
firefox121 | --- | unaffected |
firefox122 | --- | unaffected |
firefox123 | --- | verified |
People
(Reporter: robbendebiene, Assigned: gregp)
References
Details
(Keywords: dev-doc-complete)
Attachments
(2 files)
Context:
My extension Gesturefy uses getCoalescedEvents to record the detailed mouse movement in order to perform gesture detection based on that. Recently bug 1858434 landed which shortly caused a regression bug on Nightly that was (partially?) fixed by bug 1859236.
My expectation was that extensions have access to Secure Context APIs like getCoalescedEvents()
regardless of the website's Secure Context they are running in. The bug that fixed the regression uses https://searchfox.org/mozilla-central/rev/ecb14e26e11a8edd3e7110f38b3803969db618ec/dom/bindings/DOMJSClass.h#42-73 to check that. Due to my lack of understanding I cannot tell from the documentation comment whether content scripts should have access or not.
Chrome 120 doesn't limit getCoalescedEvents()
to Secure Contexts at all thus it doesn't break the functionality. In my opinion a soft limitation would lead to the best browser compatibility where getCoalescedEvents()
returns an array with a single item instead of being undefined
.
So the open question is, should content scripts running in an HTTP website have access to Secure Context APIs like getCoalescedEvents?
Notes:
- This might be somewhat of a duplicate of bug 1315029.
- Initial bug report on GitHub: https://github.com/Robbendebiene/Gesturefy/issues/696
Assignee | ||
Comment 1•11 months ago
|
||
So the open question is, should content scripts running in an HTTP website have access to Secure Context APIs like getCoalescedEvents?
See bug 1860329 and the accompanying w3c/webextension#478 discussion. The consensus among browser vendors is that content scripts in non-secure contexts should generally not have access to APIs that are annotated to require a SecureContext. However, iIndividual cases could be considered separately.
Given that, in this case, there isn't an easy workaround like using the background page, I think we should carve out an exception and give content scripts in non-secure contexts access to getCoalescedEvents
. I already wrote a patch that does this while experimenting for bug 1860329, and can put it up for review if the team agrees.
Comment 2•11 months ago
|
||
Hello,
I reproduced the issue on the latest Nightly (123.0a1/20231218171757) under Windows 10 x64 and Ubuntu 22.04 LTS based on the STR from https://github.com/Robbendebiene/Gesturefy/issues/696.
For comparison, I also tried reproducing the issue on the latest Beta (122.0b1/20231218153201) and Release (121.0/20231211174248), however the issue does not reproduce on these versions.
On Nightly, an error is also logged to console when attempting to use gestures. See attached screenshot for more details.
Comment 3•11 months ago
|
||
Comment 4•11 months ago
|
||
(In reply to robbendebiene from comment #0)
The bug that fixed the regression uses https://searchfox.org/mozilla-central/rev/ecb14e26e11a8edd3e7110f38b3803969db618ec/dom/bindings/DOMJSClass.h#42-73 to check that. Due to my lack of understanding I cannot tell from the documentation comment whether content scripts should have access or not.
That fix enables content scripts to use the feature if the document it is operating on is also allowed to do so.
Chrome 120 doesn't limit
getCoalescedEvents()
to Secure Contexts at all thus it doesn't break the functionality.
Chrome plans to remove getCoalescedEvents from Secure Contexts: https://crbug.com/1477325
In my opinion a soft limitation would lead to the best browser compatibility where
getCoalescedEvents()
returns an array with a single item instead of beingundefined
.
Sounds like a request that you could add to the Pointer Events WG, and reference https://github.com/w3c/pointerevents/issues/277.
So the open question is, should content scripts running in an HTTP website have access to Secure Context APIs like getCoalescedEvents?
The main motivation (in https://github.com/w3c/pointerevents/issues/277) is privacy concerns (fingerprinting). This is not a concern to extensions, and therefore the extension team is not opposed to exposing the API to content scripts, provided that the owners (DOM team) agrees.
Comment 5•11 months ago
•
|
||
FWIW, Chrome is also removing the API from non-secure context https://bugs.chromium.org/p/chromium/issues/detail?id=1477325
Edit: Oops, that was linked already in the comment above.
Comment 6•11 months ago
|
||
(In reply to Rob Wu [:robwu] from comment #4)
(In reply to robbendebiene from comment #0)
So the open question is, should content scripts running in an HTTP website have access to Secure Context APIs like getCoalescedEvents?
The main motivation (in https://github.com/w3c/pointerevents/issues/277) is privacy concerns (fingerprinting). This is not a concern to extensions, and therefore the extension team is not opposed to exposing the API to content scripts, provided that the owners (DOM team) agrees.
Olli, do you have concerns with exposing getCoalescedEvents
to extension's content scripts on non-SecureContexts? Any objections against exposing it?
If you do have concerns with exposing by default, would you be in favor of introducing a pref to make the availability opt-in to extensions only?
The main motivation for restricting getCoalescedEvents
to SecureContexts seems to be about privacy, and these concerns are not materially different in extensions on https vs http pages (extensions can open a new tab and make it the active document). In this WECG comment, Devlin from Chrome elaborated on two specific concerns: web page tricking the content script to leak info, and inability to perform process isolation. With this specific API I'm not too concerned with information leakage, but process isolation could potentially be relevant.
FWIW: There is a precedent for content scripts to have more powerful web platform APIs (e.g. the ability to interact with the clipboard), partially undone deprecations for extensions (bug 1850095). This all helps the few extensions that want to rely on the functionality, especially in the absence of alternatives. The selective exposure of some SecureContext-restricted APIs to extensions does increase the need to document the exceptions more clearly.
Comment 7•11 months ago
|
||
It is probably fine to expose this particular API to extensions
Assignee | ||
Comment 8•11 months ago
|
||
Updated•11 months ago
|
Comment 9•10 months ago
|
||
The severity field is not set for this bug.
:rpl, could you have a look please?
For more information, please visit BugBot documentation.
Comment 10•10 months ago
|
||
Assignee | ||
Updated•10 months ago
|
Updated•10 months ago
|
Comment 11•10 months ago
|
||
bugherder |
Comment 12•10 months ago
|
||
Verified as Fixed. Tested on the latest Nightly (123.0a1/20240103214443) under Windows 10 x64 and Ubuntu 22.04 LTS based on the STR from https://github.com/Robbendebiene/Gesturefy/issues/696.
Using the Gesturefy extension, gestures work on the page mentioned in the bug report linked above and the error shown in the screenshot from Comment 3 is no longer logged to console, confirming the fix.
Comment 13•10 months ago
|
||
The content script documentation currently makes no mention of secure or non-secure context. It only refers to "using the standard DOM APIs" which I had assumed referred to the web API DOM interfaces. The PointerEvent: getCoalescedEvents() method doesn't appear to belong to any of these interfaces.
So:
- is the assumption about the scope of "using the standard DOM APIs" incorrect?
- What is the range of Web APIs that a content script can use in a secure context?
- Is getCoalescedEvents the only method usable in a non-secure context?
Assignee | ||
Comment 14•10 months ago
•
|
||
is the assumption about the scope of "using the standard DOM APIs" incorrect? What is the range of Web APIs that a content script can use in a secure context?
I think "DOM APIs" is just colloquially referring to all web apis. Content scripts run in the context of the web page, and can therefore access all the same Web APIs that page scripts can, and then a little bit more, depending on the browser.
Is getCoalescedEvents the only method usable in a non-secure context?
The limiting of getCoalescedEvents to secure contexts is a spec change that happened a while ago and is currently in the process of being implemented in Firefox and Chrome.
This change, which is currently only enabled in Nightly, resulted in breakage in some important extensions, so it was decided that content scripts will always have access to getCoalescedEvents regardless of secureness.
At this point, getCoalescedEvents is the only [SecureContext] web api that is always available to webextension content scripts even if the page is not secure.
Comment 15•10 months ago
|
||
(In reply to rbloor from comment #13)
The content script documentation currently makes no mention of secure or non-secure context.
That should have been part of bug 1858434. I added dev-doc-needed there at https://bugzilla.mozilla.org/show_bug.cgi?id=1858434#c6
Greg has already answered the other questions, thanks :)
Updated•2 months ago
|
Description
•