The purpose of this is to allow using setHTML(text), without specifiying the sanitizer and thus always getting
the default sanitizer policy.
Differential Revision: https://phabricator.services.mozilla.com/D164677
Add support for the contentvisibilityautostatechange and fire it when
the relevancy of `content-visibility: auto` elements change.
This commit also makes some changes to the
content-visibility-auto-state-changed.html test. Two more subtests are
added which verifies that an event is sent after `content-visibility:
auto` is applied to an element. Finally the `top` element is renamed to
`upper` as `top` can also refer to the top-level Window and it seems
that Gecko has a different precedence when accessing variables in
script.
Differential Revision: https://phabricator.services.mozilla.com/D161140
When the compat mode is used, we log warnings to the JS console instead of
throwing. We also add a bunch of Glean metrics for tracking how often we
see these warnings (or failures) in the field.
Differential Revision: https://phabricator.services.mozilla.com/D161523
These interfaces are already disabled by prefs, but they are ironically
probably not well tested, so just add an extra check.
Differential Revision: https://phabricator.services.mozilla.com/D164496
When the compat mode is used, we log warnings to the JS console instead of
throwing. We also add a bunch of Glean metrics for tracking how often we
see these warnings (or failures) in the field.
Differential Revision: https://phabricator.services.mozilla.com/D161523
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
Propagate the ability to pass triggeringRemoteType through the desktop frontend
in various places, such that it is set when using the context menu or content
click handler.
Differential Revision: https://phabricator.services.mozilla.com/D161834
This includes WebTransport, WebTransportSendStream,
WebTransportReceiveStreams, WebTransportBidirectionalStream and
WebTransportError classes without any actual functionality
Differential Revision: https://phabricator.services.mozilla.com/D162323
Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
This patch implements `{Read, Write}StructuredClone` for `VideoFrame` so
`VideoFrame` can be *{de,}serialize*d.
Since VideoFrame serialization requires to serialize a member RefPtr
instance, the standard [Serializable] implementation is not possible.
The serialized data can be deserialized any number of times, including
zero. As a result, that RefPtr instance should be able to share its
reference and increase the ref-count any time it needs. Therefore, this
patch implements the [Serializable] functions in a custom fashion, which
storing the RefPtr instance in StructuredCloneHolder when serializing
the VideoFrame.
Depends on D153685
Differential Revision: https://phabricator.services.mozilla.com/D153686
This patch add `Serializable` attribute to `VideoFrame` and add some
necessary changes to make this buildable.
Some expectations of *video-frame-serialization.any.is*'s wpts are
changed to `PASS` since they are implemented in bug 1774300.
The `Verify posting closed frames throws` is currently passed by luck so
the its expectation stays the same.
Depends on D159545
Differential Revision: https://phabricator.services.mozilla.com/D153685
Add the onscrollend global event handler. The onscrollend event handler should
only be made available if the apz.scrollend-event.content.enabled preference has
been set.
Differential Revision: https://phabricator.services.mozilla.com/D160067
This patch implements `{Read, Write}StructuredClone` for `VideoFrame` so
`VideoFrame` can be *{de,}serialize*d.
Since VideoFrame serialization requires to serialize a member RefPtr
instance, the standard [Serializable] implementation is not possible.
The serialized data can be deserialized any number of times, including
zero. As a result, that RefPtr instance should be able to share its
reference and increase the ref-count any time it needs. Therefore, this
patch implements the [Serializable] functions in a custom fashion, which
storing the RefPtr instance in StructuredCloneHolder when serializing
the VideoFrame.
Depends on D153685
Differential Revision: https://phabricator.services.mozilla.com/D153686
This patch add `Serializable` attribute to `VideoFrame` and add some
necessary changes to make this buildable.
Some expectations of *video-frame-serialization.any.is*'s wpts are
changed to `PASS` since they are implemented in bug 1774300.
The `Verify posting closed frames throws` is currently passed by luck so
the its expectation stays the same.
Depends on D159545
Differential Revision: https://phabricator.services.mozilla.com/D153685
This was used to prevent reflows due to popuppositioned events during
view transitions.
The previous patch should've prevented the popuppositioned events to
begin with, plus we no longer use arrows that need positioning etc,
which means we shouldn't be triggering the reflows anyways.
Since this is the only consumer of autoPosition = true/false, we can
remove the code supporting it. It's a bit bogus as per the commit
message of the previous patch and, while fixable, it doesn't seem worth
fixing if we can just get rid of it.
Depends on D159936
Differential Revision: https://phabricator.services.mozilla.com/D159937
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
This patch creates a blank class for the VideoFrame interface. The files
are generated by running `./mach build-backend && ./mach webidl-example
VideoFrame` with necessary changes to make it buildable.
The VideoFrame interface is the essential interface for W3C WebCodecs
API, used to represent the decoded video data, decoded image, and the
data ready to be encoded.
The implementations are plain blank now. They will be filled out in the
following patches.
Depends on D144771
Differential Revision: https://phabricator.services.mozilla.com/D144772
This patch creates a blank class for the VideoColorSpace interface. The
files are generated by running `./mach build-backend && ./mach
webidl-example VideoColorSpace` with necessary changes to make it
buildable.
The VideoColorSpace is a sub-interface of the VideoFrame interface,
which is the essential building block for W3C WebCodecs API.
The implementations are plain blank now. They will be filled out in the
following patches.
Additionally, this patch creates a `dom.media.webcodecs.enabled` pref
for W3C Webcodecs API. All the WebCodecs APIs will be hidden without
setting it to `true`.
Differential Revision: https://phabricator.services.mozilla.com/D144771
This patch creates a blank class for the VideoFrame interface. The files
are generated by running `./mach build-backend && ./mach webidl-example
VideoFrame` with necessary changes to make it buildable.
The VideoFrame interface is the essential interface for W3C WebCodecs
API, used to represent the decoded video data, decoded image, and the
data ready to be encoded.
The implementations are plain blank now. They will be filled out in the
following patches.
Depends on D144771
Differential Revision: https://phabricator.services.mozilla.com/D144772
This patch creates a blank class for the VideoColorSpace interface. The
files are generated by running `./mach build-backend && ./mach
webidl-example VideoColorSpace` with necessary changes to make it
buildable.
The VideoColorSpace is a sub-interface of the VideoFrame interface,
which is the essential building block for W3C WebCodecs API.
The implementations are plain blank now. They will be filled out in the
following patches.
Additionally, this patch creates a `dom.media.webcodecs.enabled` pref
for W3C Webcodecs API. All the WebCodecs APIs will be hidden without
setting it to `true`.
Differential Revision: https://phabricator.services.mozilla.com/D144771
This is done by adding Navigator::HasMidiSupport that we reference in
the Navigator.webidl `Func` extented attribute for `requestMIDIAccess`.
A test case is added to browser_midi_permission_gated.js to ensure this
works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D157321
Implement the common steps for the next method from
https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object in
a base class, that all async iterable iterator objects inherit from. Natives
that implement an async iterable only need to implement the "getting the
next iteration result" part in their GetNextPromise method. This means they
don't have to create the object according to "CreateIterResultObject"
themselves, but can just create promise and often resolve it with a native
value directly. We've switched to a special JS::Value to signal "end of
iteration", but that's hidden inside the
iterator_utils::ResolvePromiseForFinished helper.
The WebIDL parser now uses the right return type for the generated "next"
method, which means that any exceptions in the binding code itself will
actually be correctly converted to a rejected promise instead of being
rethrown.
This also uses a class for the generated iterable iterator that's not
exposed outside the binding code. No other code should create and/or
wrap these anyway.
Differential Revision: https://phabricator.services.mozilla.com/D156323
Implement the common steps for the next method from
https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object in
a base class, that all async iterable iterator objects inherit from. Natives
that implement an async iterable only need to implement the "getting the
next iteration result" part in their GetNextPromise method. This means they
don't have to create the object according to "CreateIterResultObject"
themselves, but can just create promise and often resolve it with a native
value directly. We've switched to a special JS::Value to signal "end of
iteration", but that's hidden inside the
iterator_utils::ResolvePromiseForFinished helper.
The WebIDL parser now uses the right return type for the generated "next"
method, which means that any exceptions in the binding code itself will
actually be correctly converted to a rejected promise instead of being
rethrown.
This also uses a class for the generated iterable iterator that's not
exposed outside the binding code. No other code should create and/or
wrap these anyway.
Differential Revision: https://phabricator.services.mozilla.com/D156323
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586
- Define types that match the FedCM spec (https://fedidcg.github.io/FedCM/)
- These are not currently given in the spec, so they have to be inferred from the subsections 5.1-5.4
- I also include the GenerateInit annotation to allow deserialization later
Differential Revision: https://phabricator.services.mozilla.com/D155719
This patch creates a do-nothing IdentityCredential that gives errors when it is used.
The IdentityCredential webidl is defined here:
https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface
Accomplished here:
- IdentityCredential class defined, including isupports and cycle-counting macros
- Empty test added to hold the place of a mochitest folder
- webidl of CredentialsContainer updated and IdentityCredential added
- Logic to parse `identity` key from navigator.credentials.get()
- Adding all of this to the build, including membership to the new bugzilla component DOM: Credential Management
Differential Revision: https://phabricator.services.mozilla.com/D153588
I'm looking to implement the FedCM browser API, which hooks into the Credentail Management API.
Just cleaning up a few preference-gates in webidl and adding new preferences to use as gates.
Differential Revision: https://phabricator.services.mozilla.com/D153586
This is necessary scaffolding for testing of the HDR telemetry in a way
that involves the RDD process. This is important for matching real-world
conditions.
Depends on D155902
Differential Revision: https://phabricator.services.mozilla.com/D156245
We don't use it because we don't use theme-color, but some sites are
starting to rely on it (comment 4) and it is trivial to support.
Differential Revision: https://phabricator.services.mozilla.com/D156667
This is necessary scaffolding for testing of the HDR telemetry in a way
that involves the RDD process. This is important for matching real-world
conditions.
Depends on D155902
Differential Revision: https://phabricator.services.mozilla.com/D156245
We don't use it because we don't use theme-color, but some sites are
starting to rely on it (comment 4) and it is trivial to support.
Differential Revision: https://phabricator.services.mozilla.com/D156667
Those will be consumed by DevTools webconsole so we can order messages
emitted within the same millisecond more precisely (see next patch in queue)
Differential Revision: https://phabricator.services.mozilla.com/D155545
In particular this adds an initial implementation for the
updateTargetFrameRate method and adds the supportedFrameRates
and frameRate attributes to the XRSession.
Differential Revision: https://phabricator.services.mozilla.com/D156063
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
This also introduce a pref which protect these two attributes:
dom.picture_source_dimension_attributes.enabled.
These two dimension attributes will be mapped to the style of <img> elements
if the <source> element's parent is <picture>. This will be implemented
in the later patch. For now, we just implement the DOM interface.
Differential Revision: https://phabricator.services.mozilla.com/D152585
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
Implement it with a "no-flush" ChromeOnly option so that things like
bug 1783045 can use it without causing flashes of unstyled content, etc.
Differential Revision: https://phabricator.services.mozilla.com/D155206
It's basically an alias of setAttribute("flex", value), and it has no
remaining usage in the tree.
Since it's less useful now, let's remove the WebIDL API in favor of CSS.
Do this as a separate patch so that thunderbird / pine / etc can revert
this patch for diagnostics / to find UI with behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D154498
dom/ and dom/webidl/ : Default these files back to DOM: Core & HTML
PluginChild.jsm: Apparently this is only still used for GMP things.
browser/base/content/ : The remaining tests are mostly EME related, so I switched it over to that.
widget/tests/ : No plugin files remain, so I removed the rule.
Differential Revision: https://phabricator.services.mozilla.com/D154537
It's basically an alias of setAttribute("flex", value), and it has no
remaining usage in the tree.
Since it's less useful now, let's remove the WebIDL API in favor of CSS.
Do this as a separate patch so that thunderbird / pine / etc can revert
this patch for diagnostics / to find UI with behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D154498
This fixes a class of bugs where modifications to the RTCRtpTransceivers were
applied before sRD/sLD were completely done (while all of the JSEP and transport
stuff was finished, JS could still be working on identity-related stuff).
Differential Revision: https://phabricator.services.mozilla.com/D150173
This patch adds WebIDL bindings for the `scripting` namespace.
Note that `scripting.executeScript()` is excluded for now.
Differential Revision: https://phabricator.services.mozilla.com/D141463
unobserve() never throws. observe() only threw on a case which should
never be reached (an already unlinked observer). We can assert and
return instead.
Differential Revision: https://phabricator.services.mozilla.com/D152769
Add a pref for MouseEvent.region since that wasn't un-exposed. No other
browser supports it so we can probably safely remove it, but just in
case.
Differential Revision: https://phabricator.services.mozilla.com/D152274
Per spec, the value of fontKerning should be an enum, not a string, but currently we handle
all the keyword-valued canvas attributes in this way. We may want to convert them to enums
(which will mean that unrecognized values throw an error instead of being ignored), but I
think that should be done for all the attributes together as a separate bug. For now, using
a string here provides consistency with the rest of the canvas APIs.
Note that Blink's current implementation and the existing WPT tests have some problems:
they treat the values of fontKerning as case-insensitive, which is wrong. I have filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1343333 about this.
Differential Revision: https://phabricator.services.mozilla.com/D151755
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
This fixes websites using jakearchibald/idb@v3 which has been downloaded 1 million times in NPM (https://www.npmjs.com/package/idb).
The library creates proxies for those interfaces while assuming those are always globally available, and we get an `undefined identifier` error if those don't exist.
Only the version 3 is affected and v4+ is okay per my testing, but v3 is downloaded too many times to ignore.
Differential Revision: https://phabricator.services.mozilla.com/D151086
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
One unfortunate-ish thing of storing it in TextControlState is that we
can't preserve it across type changes, but that seems ok for now
according to my conversations with Serg.
In the future we might want to move the value to HTMLInputElement itself
or something, we'll see, but this should help folks fix some
long-standing quality issues in the password manager / autofill
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D150148
This removes HTMLMenuItemElement and all the code and tests preffed off
by dom.menuitem.enabled.
The HTML parser changes are the result of applying the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D149979
This implements dispatching a custom "MozClipboardReadTextPaste" event
to the JS side, allowing the latter to show a "Paste" button. The JS
side may then report back to the C++ side, whether the user clicked or
dismissed the "Paste" button.
Combining these features is implemented in a following part and
`clipboard.readText()` is gated behind a pref in another following part.
The implementation bundles subsequent requests of `clipboard.readText()`
belonging to the same transient user activation timestamp.
For the first request of `clipboard.readText()`, a
"MozClipboardReadTextPaste" event is dispatched. As long as no response
for the event was received, further `readText()` requests are queued.
When the response is received, the calls are either resolved or rejected.
New calls following those, within the same transient user activation
period, are resolved/rejected too.
Differential Revision: https://phabricator.services.mozilla.com/D135335