Enterprise main merge 20260212 #435
Open
+17,378
−10,714
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We already rely on one frame having at most one absolute list, so there's no point in this distinction. In the future, with position-visibility, we might want to make fixed and abspos containing block effectively the same. But one step at a time. Differential Revision: https://phabricator.services.mozilla.com/D282681
…shin,layout-reviewers Popups are already regular abspos elements in the top layer, these aren't necessary. They are also abspos and fixed pos containing blocks (via contain: paint). Differential Revision: https://phabricator.services.mozilla.com/D282682
…ewers,bjohns,czhou Differential Revision: https://phabricator.services.mozilla.com/D282537
…=skhamis,bdk,pdahiya
This just mirrors the strategy the Rust fxa component uses. The implementation is quite
simple because we were already storing cached tokens as an object (ie, as `{token: 'xxx'}),
so it's quite simple to add `expiresAt` to that object without changing the format of the
cached data.
Differential Revision: https://phabricator.services.mozilla.com/D282541
…ons to false r=rpl Differential Revision: https://phabricator.services.mozilla.com/D282215
…ation for agents, r=mossop,ai4dev-reviewers,padenot,suhaib Differential Revision: https://phabricator.services.mozilla.com/D282181
…s into a function which can be called from elsewhere. r=eeejay Previously, this was a lambda, but we will soon need to call it from SelectionManager as well. Differential Revision: https://phabricator.services.mozilla.com/D282329
…hin a document which isn't focused. r=eeejay Firing a caret event for an Accessible which doesn't have focus confuses clients, who expect that the caret should be related to the focus. Prior to bug 2006816, this wasn't as bad because even though we fired the caret event on the wrong Accessible, TextLeafPoint::GetCaret still returned the caret from the focused document. After bug 2006816, we use the cached caret, so the event and the retrieved caret are both (consistently) incorrect. To fix this: 1. Make it possible to update the RemoteAccessible cache for the caret via IPDL without firing a caret event. 2. When the caret moves, don't fire a caret event unless it's within the focused document. 3. However, the caret event won't be fired again when the document eventually gets focused, so we still send an IPDL message to update the cached caret in the RemoteAccessible tree. 4. In TextLeafPoint::GetCaret, only use the cached caret if the cached caret Accessible is within the same document as the origin Accessible. Differential Revision: https://phabricator.services.mozilla.com/D282330
… onboarding r=Mardak Differential Revision: https://phabricator.services.mozilla.com/D282705
…nd_target_files r=jonalmeida" for causing fenix bustage This reverts commit c3a52cf.
…Document()`. r=smaug Differential Revision: https://phabricator.services.mozilla.com/D281927
…smaug Differential Revision: https://phabricator.services.mozilla.com/D282162
…ILD CLOSED TREE ach -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 af -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 an -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ar -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ast -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 az -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 be -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bg -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 br -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 brx -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ca -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ca-valencia -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cak -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ckb -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cy -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 da -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 de -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 dsb -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 el -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 en-CA -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 en-GB -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 eo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-AR -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-CL -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-ES -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-MX -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 et -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 eu -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fa -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ff -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fi -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fur -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fy-NL -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ga-IE -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gd -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gu-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 he -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hi-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hsb -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hu -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hy-AM -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hye -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ia -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 id -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 is -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 it -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ja -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ja-JP-mac -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ka -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kab -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 km -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ko -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lij -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lt -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ltg -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lv -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 meh -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 mk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ml -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 mr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ms -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 my -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nb-NO -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ne-NP -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nn-NO -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 oc -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pa-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pt-BR -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pt-PT -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 rm -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ro -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ru -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sat -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sc -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 scn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sco -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 si -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 skr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 son -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sq -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sv-SE -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 szl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ta -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 te -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 tg -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 th -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 tl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 tr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 trs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 uk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ur -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 uz -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 vi -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 wo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 xh -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 zh-CN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 zh-TW -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102
…LD CLOSED TREE ach -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 an -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ar -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ast -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 az -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 be -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bg -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 br -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 bs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ca -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cak -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 cy -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 da -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 de -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 dsb -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 el -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 en-CA -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 en-GB -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 eo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-AR -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-CL -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-ES -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 es-MX -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 et -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 eu -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fa -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ff -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fi -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 fy-NL -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ga-IE -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gd -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 gu-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 he -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hi-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hsb -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hu -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 hy-AM -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ia -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 id -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 is -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 it -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ja -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ka -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kab -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 km -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 kn -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ko -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lij -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lt -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ltg -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 lv -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 meh -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 mix -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ml -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 mr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ms -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 my -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nb-NO -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ne-NP -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 nn-NO -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 oc -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pa-IN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pt-BR -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 pt-PT -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 rm -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ro -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ru -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 son -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sq -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 sv-SE -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ta -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 te -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 th -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 tl -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 tr -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 trs -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 uk -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 ur -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 uz -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 vi -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 wo -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 xh -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 zam -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 zh-CN -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102 zh-TW -> 29bdbdb5d765a5a5c206175fab21d216f8fd0102
…er to apply volume change on the media element source node properly. r=media-playback-reviewers,pehrsons,karlt In this patch, we let MediaElementAudioSourceNode directly monitor the effective volume change from the HTMLMediaElement in order to achieve the same volume level output from the graph per spec [1]. We also remove the existing path on AudioDecoderInputTrack that sets the volume, so that applying volume via AudioNodeExternalInputTrack becomes the only path to adjust volume for MediaElementAudioSourceNode. This WILL change the behavior of captureStream/mozCaptureStream and mozCaptureStreamUntilEnded, making the stream volume independent of changes to the original media element’s volume. In addition, the volume of a media element volume is now applied to MediaElementAudioSourceNode capture even with MediaStream srcObject. [1] https://webaudio.github.io/web-audio-api/#MediaElementAudioSourceNode Differential Revision: https://phabricator.services.mozilla.com/D279751
… output reflects HTMLMediaElement effective volume change. r=pehrsons,karlt Differential Revision: https://phabricator.services.mozilla.com/D280463
…Stream is unaffected by its source element's effective volume change. r=pehrsons Differential Revision: https://phabricator.services.mozilla.com/D280493
…nd add volume tests. r=pehrsons This patch switches to using ScriptProcessorNode to compute RMS, replacing the previous approach based on AnalyserNode. It also adds additional test cases to ensure that volume changes on the loopback stream behave as expected. Differential Revision: https://phabricator.services.mozilla.com/D281715
…Node. r=pehrsons Differential Revision: https://phabricator.services.mozilla.com/D281716
…-reviewers,pehrsons Window audio capture now captures all audio sources at full volume, regardless of the mute state of individual elements, so we need to update the TODO for test_getUserMedia_audioCapture. In addition, we add await for play promises to avoid intermittent failure to ensure analyser can check audible data after all sources start playing. Differential Revision: https://phabricator.services.mozilla.com/D282115
Differential Revision: https://phabricator.services.mozilla.com/D282533
…Scope` in favor of explicit dispatcher parameters. r=android-reviewers,android-addons-reviewers,rebecatudor273,jonalmeida - Update numerous features to accept a `mainDispatcher` (defaulting to `Dispatchers.Main`). - Refactor unit tests to use `StandardTestDispatcher`, `runTest`, and `advanceUntilIdle()` for deterministic testing of asynchronous state changes. Differential Revision: https://phabricator.services.mozilla.com/D282190
…pref r=gsvelto Differential Revision: https://phabricator.services.mozilla.com/D282693
We used to be able to select which edges get anti-aliased for linear gradient primitives. That got lost in the transition to quads and is needed for all other patterns. This patch adds plumbing for specifying which edges to antialias with two possible configurations: with or without an axis-aligned transform. CSS primitives don't anti-alias axis-aligned primitives, but SVG primitives should (alas they currently don't). I suspect that with upocming changes to snapping we may end up representing this distinction some other way, but with this patch, the code internally at least reflects the options that we need to eventually support correctly. For now the most pressing concern is that primitives need to be able to not anti-alias certain edges to avoid seams within items that are segmented inot multiple primitives. This is already the case of linear and radial gradients in some situations, and will probably be needed for the segmentation of border nine-patches. Differential Revision: https://phabricator.services.mozilla.com/D282374
… anti-aliased. r=gw Differential Revision: https://phabricator.services.mozilla.com/D282375
…primitive segmentation. r=gw Differential Revision: https://phabricator.services.mozilla.com/D282376
…t error - r=niklas Differential Revision: https://phabricator.services.mozilla.com/D281527
…ssed - r=niklas Differential Revision: https://phabricator.services.mozilla.com/D281567
As explained in bug 2015895, extension popups are not closed on Android when an extension unloads. That is a pre-existing bug, and will cause test failures when we start rejecting `action.openPopup()` calls when another extension popup is present. As a work-around, this patch explicitly closes popups that were opened during the test. These can be removed when bug 2015895 is fixed. Differential Revision: https://phabricator.services.mozilla.com/D282736
…ewers,ohall Differential Revision: https://phabricator.services.mozilla.com/D280519
The tests are for browserAction.openPopup, but the implementation is identical between action.openPopup and browserAction.openPopup. Differential Revision: https://phabricator.services.mozilla.com/D280761
These will be useful in a later part when StructuredCloneData and its subclasses are refactored. Currently we adopt data into a StructuredCloneHolder indirectly by using `ReadFromBuffer` to read from an externally-managed buffer, but this new method allows adopting the data directly into the buffer within StructuredCloneHolder. Differential Revision: https://phabricator.services.mozilla.com/D281110
…der::Read, r=asuth This was always identical to the current global, with the existing ReadFullySerializableObjects method already depending on that. Removing the mGlobal member from StructuredCloneHolder is part of reducing mutations during !mSupportsTransferring reads. In a later part, we will need to support concurrent reads in this case. Differential Revision: https://phabricator.services.mozilla.com/D281111
…der::Read, r=asuth,dom-worker-reviewers Now that we are no longer tracking the global on the StructuredCloneHolder type (see previous patch), this argument is redundant, and can be removed. Differential Revision: https://phabricator.services.mozilla.com/D281112
…zing StructuredCloneHolder, r=asuth,dom-worker-reviewers This is the last member of StructuredCloneHolder which is mutated when reading a StructuredCloneHolder which does not support transfers. This does change behaviour, as the Read functions no longer clobber every exception thrown by the StructuredClone implementation with a DataCloneError exception, instead stealing the exceptions as they are thrown. The behaviour of the Write function has been changed less substantially, as it already avoided clobbering existing exceptions. This change in behaviour is not a complete shift. Our Structured Clone custom callbacks have historically not reliably thrown exceptions on failure, so uncatchable exceptions are replaced with generic exceptions before being returned to the JS engine to avoid throwing uncatchable exceptions in error cases where we did not previously. It's worth noting that this change assumes that the JS implementation of structured clone reliably throws exceptions itself. In general SpiderMonkey code is better about this (due to better-established patterns), than Gecko code using SpiderMonkey calling conventions. The new implementations of Read/Write use StealExceptionFromJSContext over NoteJSContextException, as SuppressExceptions/IgnoreErrors/IgnoredErrorResult are frequently used with StructuredCloneHolder, and JSContext exceptions are not suppressed when SuppressExceptions is called. Differential Revision: https://phabricator.services.mozilla.com/D281113
…nsferrables, r=asuth This already would not have worked (as you cannot transfer a transferrable to multiple destinations at the same time). This makes it explicit, preventing future code from being added and breaking things, and ensuring that codepaths in StructuredCloneHolder which mutate the object during Read will not. We already disable transferrables in this way for BroadcastChannel, but this codepath was likely missed due to only being used by internal system JS. Differential Revision: https://phabricator.services.mozilla.com/D281114
…r, r=smaug This was never used outside of tests, and adds a substantial amount of complexity to the nsFrameMessageManager's ReceiveMessage implementation, which is going to be further rewritten in the next part. Differential Revision: https://phabricator.services.mozilla.com/D281552
… r=asuth Previously, we would copy the data and deserialize it once for each listener. This interacts poorly with the actual data which can be sent over the message manager, as it is possible to include transferables (which must only be deserialized once). This new approach ensures that the data structure is always deserialized once in the shared scope, and then passed to all of the listeners, avoiding issues with deserializing the same transferable multiple times. Differential Revision: https://phabricator.services.mozilla.com/D281553
…diate, r=asuth,mccr8,extension-reviewers,dom-worker-reviewers,robwu
This patch is to remove the ClonedMessageData type which is currently
frequently used for sending a StructuredCloneData over IPC manually. Instead,
under the new approach, the StructuredCloneData is transferred directly using
its serializer.
This allows for simplification of various types across the codebase which
previously needed complex handling for this manual {de-}serialization step,
especially around keeping the borrowed-from buffers alive in some cases.
As part of this, the type has also been changed to be a threadsafe refcounted
object. This is in part possible due to earlier parts, which have made it safe
to Read() from the same StructuredCloneData object concurrently from multiple
threads (so long as it does not support transferrables).
The underlying data storage within StructuredCloneData was previously already
reference counted (due to SharedJSAllocatedData).
In addition to StructuredCloneData, other data structures (e.g.
nsStructuredCloneContainer and SharedMessageBody) have also been updated to be
serialized directly, avoiding now-unnecessary intermediate objects.
Differential Revision: https://phabricator.services.mozilla.com/D281115
…asuth This method was only used by the old StructuredCloneData implementation, and is no longer necessary. Differential Revision: https://phabricator.services.mozilla.com/D281116
…iner, r=asuth,extension-reviewers,spidermonkey-reviewers,sfink,robwu This appears to have been broken in bug 1302036. Fortunately, no logic currently changes behaviour based on structured clone buffer version in JS right now, but if this changes, this avoids potential migration issues. When looking at this, I did notice a particular instance in `AddonManagerStartup::DecodeBlob` which appears to be reading a blob from disk without specifying a version number. So far I've considered fixing that to track the version number as well out-of-scope for this bug. Differential Revision: https://phabricator.services.mozilla.com/D281117
…cturedCloneHolder, r=asuth This adds more assertions in various places, and ensures that things like StructuredCloneData's serialization is updated when new members are added to StructuredCloneHolder. This is done by adding helper methods returning `std::tie`-ed tuples of the various attachment array types, which can then be handled using `std::apply` and parameter packs. Differential Revision: https://phabricator.services.mozilla.com/D281554
…asuth This makes a couple of changes to the data types as they're serialized in StructuredCloneData (by changing the type in StructuredCloneHolder). Specifically, this uses a new "EagerIPCStream" wrapper which is serialized eagerly instead of lazily, avoiding issues with input stream types used for the about home cache when using lazy input streams. Differential Revision: https://phabricator.services.mozilla.com/D282470
…alker,tabbrowser-reviewers The TabNotesController and TabNotes machinery currently assumes that `browser.tabs.notes.enabled` is either enabled or disabled during a user's entire session. This patch does a few things: 1. instead of just relying on the category manager to govern the life cycle for TabNotesController, that class also reacts to changes in the tab notes pref 2. since the TabNotesController depends on the CanonicalURL actor being ready after enabling the tab notes pref, the communication chain is pref -> DesktopActorRegistry -> TabNotesController instead of pref -> TabNotesController. 3. When turned on while the browser is running, we connect to TabNotes storage and ask all open tabs to parse for their canonical URLs. When turned off while the browser is running, we disconnect from TabNotes storage and clear all canonical URL/tab notes state on all tabs. Differential Revision: https://phabricator.services.mozilla.com/D279983
…causing multiple failures. DONTBUILD This reverts commit ac29ad6. Revert "Bug 2009206 - Remove advanced resolvers - r=niklas" This reverts commit 7435f9e. Revert "Bug 2009206 - Restore HSTS text that explains why error can't be bypassed - r=niklas" This reverts commit 51c27b9. Revert "Bug 2009206 - Show error code on error page, even when there's no cert error - r=niklas" This reverts commit 80bbf26. Revert "Bug 2009206 - Rename context arguments in error-lookup.mjs - r=niklas" This reverts commit a843cc9. Revert "Bug 2009206 - Refactor advanced section resolvers - r=niklas" This reverts commit 805bae8. Revert "Bug 2009206 - Remove findSupportedErrorCode - r=niklas" This reverts commit 304c511. Revert "Bug 2009206 - Rename introContent params - r=niklas" This reverts commit 125ed42. Revert "Bug 2009206 - Migrate remaining legacy errors to Felt Privacy experience, remove useLegacy flag - r=niklas,hjones" This reverts commit 88575c2. Revert "Bug 2009206 - Added id fields to all error configs, removed CUSTOM_ERROR_CODE_MAP - r=niklas" This reverts commit d2216e2. Revert "Bug 2009206 - Moved image selection to the error configs. - r=niklas" This reverts commit d746243. Revert "Bug 2009206 - Set page title according to category param. - r=niklas" This reverts commit def375a. Revert "Bug 2009206 - Added an advancedResolver, fixed missing page content, added missing error configs, fixed tests. - r=niklas" This reverts commit 04a2f53. Revert "Bug 2009206 - Add some more error codes to the registry, need to fix configurations for them - r=niklas" This reverts commit 38c960d. Revert "Bug 2009206 - Use isFeltPrivacySupported for proper Felt Privacy v1 gating and deduplicate error code mappings. - r=niklas" This reverts commit a480b18. Revert "Bug 2009206 - Integrate error registry with aboutNetError.mjs for legacy error pages. - r=niklas" This reverts commit 89969ae. Revert "Bug 2009206 - Integrate error registry with net-error-card.mjs for Felt Privacy v1 experience. - r=niklas" This reverts commit 798f3a4. Revert "Bug 2009206 - Add error configurations for certificate and network errors. - r=niklas" This reverts commit 0b9d463. Revert "Bug 2009206 - Add error registry foundation for network/certificate error pages. - r=niklas" This reverts commit a1c1e2c.
…d strings - r=ip-protection-reviewers,fluent-reviewers,omc-reviewers,kpatenio,bolsson,aminomancer" for causing failures at browser_all_files_referenced.js. This reverts commit cab800b.
…nge r=dwalker,tabbrowser-reviewers" for causing failures at browser_tab_notes_enable_disable.js. This reverts commit a165709.
…rs,sclements Differential Revision: https://phabricator.services.mozilla.com/D281578
Uh oh! Looks like an error!Client ID static/taskcluster/github does not have sufficient scopes and is missing the following scopes: This request requires the client to satisfy the following scope expression:
|
Uh oh! Looks like an error!Client ID static/taskcluster/github does not have sufficient scopes and is missing the following scopes: This request requires the client to satisfy the following scope expression:
|
Uh oh! Looks like an error!Client ID static/taskcluster/github does not have sufficient scopes and is missing the following scopes: This request requires the client to satisfy the following scope expression:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.