Trusted Types checks for onmessage and onreadystatechange attributes
Categories
(Core :: DOM: Events, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox137 | --- | fixed |
People
(Reporter: fredw, Assigned: fredw)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed)
Attachments
(2 files)
Tests:
- set-event-handlers-content-attributes.tentative.html
- TrustedTypePolicyFactory-getAttributeType-event-handler-content-attributes.tentative.html
Spec:
- TT: https://w3c.github.io/trusted-types/dist/spec/#abstract-opdef-get-trusted-type-data-for-attribute (and https://github.com/w3c/trusted-types/issues/520)
- WindowEventHandlers's onmessage: https://html.spec.whatwg.org/multipage/webappapis.html#windoweventhandlers
- Document's onreadystatechange: https://html.spec.whatwg.org/#the-document-object:handler-onreadystatechange
Implementation:
- TT: https://searchfox.org/mozilla-central/rev/a965e3c683ecc035dee1de72bd33a8d91b1203ed/dom/security/trusted-types/TrustedTypeUtils.cpp#599
- nsContentUtils: https://searchfox.org/mozilla-central/rev/a965e3c683ecc035dee1de72bd33a8d91b1203ed/dom/base/nsContentUtils.cpp#1016
onmessage is an event handler attribute of body/frameset but we use the EventNameType_None flag. Probably the onmessage content attribute does not work on body right now and there is a FIXME message:
https://searchfox.org/mozilla-central/rev/a965e3c683ecc035dee1de72bd33a8d91b1203ed/dom/events/EventNameList.h#300
// XXXbz Should the onmessage attribute on <body> really not work? If so, do we
// need a different macro to flag things like that (IDL, but not content
// attributes on body/frameset), or is just using EventNameType_None enough?
WINDOW_EVENT(message, eMessage, EventNameType_None, eBasicEventClass)
onreadystatechange is a document event and not an event handler attribute of any DOM element, however we use the EventNameType_HTMLXUL flag. Because nsContentUtils does not make a distinction for DOCUMENT_ONLY_EVENT (or WINDOW_ONLY_EVENT etc), it is currently wrongly treated as a event handler content attribute for TT.
DOCUMENT_ONLY_EVENT(readystatechange, eReadyStateChange, EventNameType_HTMLXUL,
eBasicEventClass)
Probably we would need a nsContentUtils::EventHandlerContentAttributeName that checks an extra flag. Defining FORWARDED_EVENT to set the flag a seems to be what we want, but we should make sure that still works for "HTMLMediaElement" (seems to be using EVENT macro) or "SVGAnimationElement" (seems to be using NON_IDL_EVENT macro).
|
||
Updated•24 days ago
|
|
Assignee | |
Comment 1•23 days ago
|
||
|
|
Assignee | |
Comment 2•23 days ago
|
||
WINDOW_ONLY_EVENT and DOCUMENT_ONLY_EVENT are not supposed to be used for event
names corresponding to event handler content attributes. However, the
EventNameType_HTML bit is set for onreadystatechange and onvisibilitychange
attributes, and this bit is used here:
- EventNameType_All: Only used in TrustedTypeUtils.cpp to treat attributes as
TrustedScript sinks for attribute mutation and
TrustedTypePolicyFactory.getAttributeType(). - EventNameType_HTML: Only used in nsIContent::IsEventAttributeName() (via its
Internal version) to register event handlers on HTML elements and treat
attributes as JavaScript in the XML serializer. - EventNameType_HTMLXUL: Not used outside EventNameList.h
This patch stops treating onreadystatechange/onvisibilitychange as HTML content
attributes and only treat them as IDL attributes on the Document object:
https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects
TODO: add intent to unship.
|
|
Assignee | |
Updated•23 days ago
|
|
||
Updated•23 days ago
|
|
|
||
Updated•23 days ago
|
|
|
Assignee | |
Comment 3•23 days ago
|
||
Probably the onmessage content attribute does not work on body right now and there is a FIXME message:
Testcase: data:text/html,<body onmessage="alert('Hello World!')" onload="this.dispatchEvent(new Event('message'))">
Probably we would need a nsContentUtils::EventHandlerContentAttributeName that checks an extra flag. Defining FORWARDED_EVENT to set the flag a seems to be what we want, but we should make sure that still works for "HTMLMediaElement" (seems to be using EVENT macro) or "SVGAnimationElement" (seems to be using NON_IDL_EVENT macro).
So it turned out this suggestion was wrong, I think we just don't need the EventNameType_HTML bit (probably EventNameType_XUL either).
Testcase: data:text/html,<div id="x" onreadystatechange="alert('Unexpected event!')"><script>x.dispatchEvent(new Event("readystatechange"))</script>
|
||
Updated•21 days ago
|
https://hg.mozilla.org/mozilla-central/rev/c8dfc7a544b4
https://hg.mozilla.org/mozilla-central/rev/fba1faefa13a
https://hg.mozilla.org/mozilla-central/rev/06c418a8e2bb
Description
•