Addresses the problem of cached manifests having the wrong associated browser.
However, this is only temporary solution, as cached manifests can have different
associated browsers (e.g., if 3x more tabs are open, this will still potentially be racy).
Differential Revision: https://phabricator.services.mozilla.com/D49706
--HG--
extra : moz-landing-system : lando
Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
After sw-e10s enabled in nightly, following tests should be passsed with Fission
dom/serviceworkers/test/browser_devtools_serviceworker_interception.js
dom/serviceworkers/test/test_cookie_fetch.html
dom/serviceworkers/test/test_csp_upgrade-insecure_intercept.html
dom/serviceworkers/test/test_eventsource_intercept.html
dom/serviceworkers/test/test_hsts_upgrade_intercept.html
dom/serviceworkers/test/test_https_fetch.html
dom/serviceworkers/test/test_https_fetch_cloned_response.html
dom/serviceworkers/test/test_https_origin_after_redirect.html
dom/serviceworkers/test/test_https_origin_after_redirect_cached.html
dom/serviceworkers/test/test_https_synth_fetch_from_cached_sw.html
dom/serviceworkers/test/test_importscript_mixedcontent.html
dom/serviceworkers/test/test_sanitize_domain.html
This patch enables these tests.
Differential Revision: https://phabricator.services.mozilla.com/D50032
--HG--
extra : moz-landing-system : lando
`uint32_t`, because `nsRange::ComparePoints` requires it -- by webidl
interface -- to be unsigned long.
Moreover it makes `RangeBoundaryBase`'s interface cleaner, because it
already exposes the offset as a `uint32_t`.
Differential Revision: https://phabricator.services.mozilla.com/D50054
--HG--
extra : moz-landing-system : lando
The idea is to stop directly accessing EnumTypeValues::strings in type-unsafe
ways from consumer code.
Differential Revision: https://phabricator.services.mozilla.com/D49533
--HG--
extra : moz-landing-system : lando
Returning a span ensures that consumers don't try to use this without a length,
but does hide the fact that our string is always null-terminated, at least for
the moment...
Differential Revision: https://phabricator.services.mozilla.com/D49531
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
This completes my review of skipped Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D49954
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
This is necessary as the nsFrameLoader may have been swapped, due to a process
switch, before the teardown of the old nsDocShell is complete. In this case, the
nsDocShell is still present on the BrowsingContext despite a nsFrameLoader for a
remote frame having been set up.
This will also be important for future changes such as cross-process bfcache. It
may be possible to change the calls to `nsFrameLoader::GetDocShell()` back to
`mDocShell` accesses in the future.
Differential Revision: https://phabricator.services.mozilla.com/D49648
--HG--
extra : moz-landing-system : lando
If these are fired too early, a nested event loop can be spun before the new
nsFrameLoader has been set up. Messages can be received over the
BrowserBridgeChild actor during this time when no nsFrameLoader is set, causing
crashes.
Differential Revision: https://phabricator.services.mozilla.com/D49647
--HG--
extra : moz-landing-system : lando
It does not achieve anything and crashes if the log module manager hasn't been
initialized.
Differential Revision: https://phabricator.services.mozilla.com/D49958
--HG--
extra : moz-landing-system : lando
* This patch makes pages with the `OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP` policy load into a special `webCOOP+COEP={pageOrigin}` remote type.
* Adds `E10SUtils.WEB_REMOTE_COOP_COEP_TYPE_PREFIX="webCOOP+COEP="`
* When a COOP process switch occurs and the target page doesn't have this policy, we pass a `preferredRemoteType="web"` into `E10SUtils.getRemoteTypeForPrincipal` ensuring that we correctly get a different `remoteType`
* E10SUtils.getRemoteTypeForPrincipal is changed such that `if preferredRemoteType.startsWith(WEB_REMOTE_COOP_COEP_TYPE_PREFIX)` we don't override it with `webIsolated={pageOrigin}`.
* `coop_header.sjs` is changed to also allow setting `Cross-Origin-Embedder-Policy` headers
* `browser_httpCrossOriginOpenerPolicy.js` is changed to test that pages are correctly opened in the correct remoteType process.
Differential Revision: https://phabricator.services.mozilla.com/D48715
--HG--
extra : moz-landing-system : lando
Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
Owing to a lack of test coverage, the changes in bug 1469048 regressed our
de facto privacy/devtools API at nsIServiceWorkerManager.propagateUnregister
to no longer wipe the given registration. The intent of that bug's changes
was to stop the now-moot propagation, but that particular intentional mis-use
of the API was missed.
This patch fixes the problem but maintains the parent-intercept behavior of
only calling ServiceWorkerRegistrar::UnregisterServiceWorker only once.
Differential Revision: https://phabricator.services.mozilla.com/D49996
--HG--
extra : moz-landing-system : lando
This patch introduces a Speech Recognition Service which interfaces with Mozilla's remote STT endpoint which is currently being used by multiple services
Differential Revision: https://phabricator.services.mozilla.com/D26047
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
Where possible I ported tests to use the shadow DOM. The following could
potentially be ported, but don't think it worth of it:
test_bug414907.xul - uses children nodes in constructor which is very
different in shadow DOM world
test_bug233643.xul - really tests XBL behavior
test_anonymous_content.py - bug on file already to create shadow DOM
test from scratch
Differential Revision: https://phabricator.services.mozilla.com/D49341
--HG--
rename : devtools/client/inspector/test/browser_inspector_highlighter-xbl.js => devtools/client/inspector/test/browser_inspector_highlighter-custom-element.js
extra : moz-landing-system : lando
This patch converts the certList attribute of nsITransportSecurityInfo
from nsIX509CertList to Array<nsIx509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D48745
--HG--
extra : moz-landing-system : lando
* This patch makes pages with the `OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP` policy load into a special `webCOOP+COEP={pageOrigin}` remote type.
* Adds `E10SUtils.WEB_REMOTE_COOP_COEP_TYPE_PREFIX="webCOOP+COEP="`
* When a COOP process switch occurs and the target page doesn't have this policy, we pass a `preferredRemoteType="web"` into `E10SUtils.getRemoteTypeForPrincipal` ensuring that we correctly get a different `remoteType`
* E10SUtils.getRemoteTypeForPrincipal is changed such that `if preferredRemoteType.startsWith(WEB_REMOTE_COOP_COEP_TYPE_PREFIX)` we don't override it with `webIsolated={pageOrigin}`.
* `coop_header.sjs` is changed to also allow setting `Cross-Origin-Embedder-Policy` headers
* `browser_httpCrossOriginOpenerPolicy.js` is changed to test that pages are correctly opened in the correct remoteType process.
Differential Revision: https://phabricator.services.mozilla.com/D48715
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This is necessary as the nsFrameLoader may have been swapped, due to a process
switch, before the teardown of the old nsDocShell is complete. In this case, the
nsDocShell is still present on the BrowsingContext despite a nsFrameLoader for a
remote frame having been set up.
This will also be important for future changes such as cross-process bfcache. It
may be possible to change the calls to `nsFrameLoader::GetDocShell()` back to
`mDocShell` accesses in the future.
Differential Revision: https://phabricator.services.mozilla.com/D49648
--HG--
extra : moz-landing-system : lando
If these are fired too early, a nested event loop can be spun before the new
nsFrameLoader has been set up. Messages can be received over the
BrowserBridgeChild actor during this time when no nsFrameLoader is set, causing
crashes.
Differential Revision: https://phabricator.services.mozilla.com/D49647
--HG--
extra : moz-landing-system : lando
It's perfectly possible to create unstable filter, that can easily go to
infinity, so this assert is not valid.
Differential Revision: https://phabricator.services.mozilla.com/D49608
--HG--
extra : moz-landing-system : lando
This also adds a GetLinearStringCharAt helper function to simplify GetArrayIndexFromId.
Differential Revision: https://phabricator.services.mozilla.com/D49723
--HG--
extra : moz-landing-system : lando
This is where it should have been in the first place. Those attributes belong there.
Differential Revision: https://phabricator.services.mozilla.com/D49577
--HG--
extra : moz-landing-system : lando
The variables in this function are really unsigned values in disguise. Ideally they'd be something like `UIntSize` but that's not a thing. As a path of least resistance, let's check that they're greater than zero to rule out absurdly large unsigned values (which would have been ruled out by the `MAX_DIMENSION` test anyway). And then we no longer need the a*b != 0 tests.
Differential Revision: https://phabricator.services.mozilla.com/D49666
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
When `nsTextEditorState::SetValue()` is called with `eSetValue_BySetUserInput`,
we emulate user input. I.e., keep using transaction manager of the editor,
events fired while handling user input should be fired.
Currently, `nsTextEditorState::SetValue()` suppresses multiple state handling
while setting value with calling `mTextListener->SettingValue(true)`. This
is why `"input"` event listeners cannot retrieve the latest state of validation
if `inputType` is `"insertReplacementText"`.
This patch makes it keep managing `mTextListener` when setting the value
programatically. Otherwise, i.e., it emulates user input, editor should
manage it from `EditorBase::NotifyEditorObservers()` instead so that this
patch makes it not managing `mTextListener` in such case.
Differential Revision: https://phabricator.services.mozilla.com/D49571
--HG--
extra : moz-landing-system : lando
It can be unset by NotifyShutdown, to release the VideoFrameContainer in time.
This is unexpected for all paths assuming it will be unset by
EndSrcMediaStreamPlayback().
Depends on D49573
Differential Revision: https://phabricator.services.mozilla.com/D49574
--HG--
extra : moz-landing-system : lando
WebAudio upmix layout is defined in the spec for the channel configurations mono, stereo, quad and 5.1. Layouts with 3 and 5 channels are not defined yet. For those undefined layouts firefox provided upmix to a single channel (left). This has been updated to upmix to the two stereo channels (left, right).
Differential Revision: https://phabricator.services.mozilla.com/D49610
--HG--
extra : moz-landing-system : lando
When Fission is on, loading a cross-origin iframe triggers process switching when calling the channel::OnStartReqeust.
If a ServiceWorker should intercept the loading, the interception setting is completed while opening the channel.
That means the service worker controls the ClientSource created by the old process.
After process switching completed, the new ClientSource will be created and resume the loading from the opened channel.
However, in the original code, we did not update the controlled Client in the ServiceWorkerManager.
And when loading the same origin subresource in the new process, it makes ServiceWorkerManager cannot find the correct ServiceWorker to perform the interception.
Since we are going to release sw-e10s, this patch is only for both Fission and sw-e10s are on.
Differential Revision: https://phabricator.services.mozilla.com/D49284
--HG--
extra : moz-landing-system : lando
The fetchIcon() bug is labelled as async, but doesn't use await. Refactoring it to use await cleans up the function a bit.
Differential Revision: https://phabricator.services.mozilla.com/D49581
--HG--
extra : moz-landing-system : lando
Bug 1587521 - Enable FullScreen in FxR for Desktop
This change enables Fullscreen functionality in the UI for Firefox Reality for Desktop. On Fullscreen, the window (rather than the desktop) is taken over, and it is up to the host to render the contents as fullscreen.
To mitigate the impact on Desktop's implementation, browser-fullScreenAndPointerLock.js is forked and removes the dependencies on browser.js. These two files will be rationalized at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D48913
--HG--
rename : browser/base/content/browser-fullScreenAndPointerLock.js => browser/fxr/content/fxr-fullScreen.js
extra : moz-landing-system : lando
This is effectively a reversion of the change made in
https://hg.mozilla.org/mozilla-central/rev/89c938649297#l1.39 when
DOMMozPromiseRequestHolder was introduced. I've tried to add some
comments to contextualize what's happening there and why it differs
from other similar callsites.
Longer term we might move to just deleting the underlying actor when
we are disconnected. Those actors were written assuming an
execution model where letting either end delete the actor would result
in intentional process crashes when a message was received for a
destroyed actor. That is no longer the case.
Differential Revision: https://phabricator.services.mozilla.com/D49671
--HG--
extra : moz-landing-system : lando
The changes to the IDL files were done by running this in dom/webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor,\n Exposed=Window\]\ninterface ([A-Za-z]+) : HTMLElement \{/[Exposed=Window]\ninterface \1 : HTMLElement {\n [HTMLConstructor] constructor();\n/g' *.webidl
and then fixing any remaining parser failures. That involved hand-editing the
following files:
TestCodeGen.webidl
XULFrameElement.webidl
XULMenuElement.webidl
XULTextElement.webidl
XULTreeElement.webidl
HTMLAudioElement.webidl
HTMLDialogElement.webidl
HTMLElement.webidl
HTMLEmbedElement.webidl
HTMLFormElement.webidl
HTMLImageElement.webidl
HTMLObjectElement.webidl
HTMLOptionElement.webidl
HTMLSlotElement.webidl
HTMLVideoElement.webidl
XULElement.webidl
XULPopupElement.webidl
Differential Revision: https://phabricator.services.mozilla.com/D49349
--HG--
extra : moz-landing-system : lando
The other cases when ClearWindowProxy is called seem to be fine.
It is the Unlink case which was causing null .contentWindow with test_mozfiledataurl.html
Fixes bug 1580391 and backs out bug 1581004
Differential Revision: https://phabricator.services.mozilla.com/D48878
--HG--
extra : moz-landing-system : lando
WebAudio upmix layout is defined in the spec for the channel configurations mono, stereo, quad and 5.1. Layouts with 3 and 5 channels are not defined yet. For those undefined layouts firefox provided upmix to a single channel (left). This has been updated to upmix to the two stereo channels (left, right).
Differential Revision: https://phabricator.services.mozilla.com/D49610
--HG--
extra : moz-landing-system : lando
Note that nsDocShell::NotifyJSRunToCompletionStart ends up passing this string to
JavascriptTimelineMarker where the constructor assigns it to |nsString mFunctionName|
so there should be no difference between passing nullptr or empty string.
Differential Revision: https://phabricator.services.mozilla.com/D49391
--HG--
extra : moz-landing-system : lando
This does a bit of a cleanup, where changing the notification to waiting for
removal is the major task. It also removes the special handling of not informing
listeners of shutdown on Cancel(), and a bit of cleanup around MozPromise usage.
Differential Revision: https://phabricator.services.mozilla.com/D49416
--HG--
extra : moz-landing-system : lando
We use SystemParametersInfo to get the current system scroll wheel settings when we process scrollwheel movement in the content process. We need to remove SystemParametersInfo for sandboxing the content process so this code changes the plugin behavior to cache the system wheel settings. We do this by 1) sending wheel settings to the plugin whenever a plugin takes focus and 2) forwarding wheel settings update messages from Windows to the currently focused plugin.
Differential Revision: https://phabricator.services.mozilla.com/D47938
--HG--
extra : moz-landing-system : lando
As part of sandboxing the content process for Windows, we want to remove these calls from it. These instances of GetKeyState should not be in actual use since plugin mouse events are handled through different means. When they come to nsPluginInstanceOwner::ProcessEvent, they come with a pre-filled-in mPluginEvent, and this code is conditional on that not happening. Despite that, I am preserving the existing behavior by moving the GetKeyState calls to the plugin process (where they are brokered to the parent process). This fix is more robust to change than just removing the code would be.
Differential Revision: https://phabricator.services.mozilla.com/D47937
--HG--
extra : moz-landing-system : lando
GetForegroundWindow in PluginInstanceParent is used as part of message throttling in windowed plugins -- which we no longer officially support. We need to remove it from normal behavior for sandboxing the content process as part of win32k-lockdown. We are not removing windowed plugin code yet so, rather than break the behavior, I've gated the win32 calls so that they aren't run with windowless plugins.
Note that the original behavior was fine as the sandbox just makes the function return NULL -- but it would still show up in stack analysis so the behavior in this patch is preferred.
Differential Revision: https://phabricator.services.mozilla.com/D47936
--HG--
extra : moz-landing-system : lando
This message was always being created in the constructor for nsPluginNativeWindowWin. We want to remove RegisterWindowMessage from content for sandboxing (win32k-lockdown). The message is only used in the old windowed plugin behavior, which is no longer supported, although the code remains in the code base. I've simply moved RegisterWindowMessage to the windowed plugin path instead of removing it, since there is no need to break it.
Differential Revision: https://phabricator.services.mozilla.com/D47935
--HG--
extra : moz-landing-system : lando
All but browser_bug744745.js seem to pass even without the fixes I
made, which seems odd.
browser_bug1058164.js is a little odd because it passes in {} instead
of a boolean for the useCapture argument. I think this ends up calling
addEventListener(..., {}, false), which should be the equivalent of
addEventListener(..., {}).
Differential Revision: https://phabricator.services.mozilla.com/D49453
--HG--
extra : moz-landing-system : lando
Mark Banner
Geoff Lankow
Tim Nguyen
Marcos Cáceres
Thomas Nguyen
Jean-Yves Avenard
Jeff Gilbert
Andrew Sutherland
Christoph Kerschbaumer
Andreea Pavel
Eden Chuang
Andreas Pehrson
Tom Ritter
Mirko Brodesser
Razvan Maries
Tom Tung
Kagami Sascha Rosylight
Andrea Marchesini
Boris Zbarsky
Daniel Varga
Kashav Madan
Geoff Brown
Matt Woodrow
Sebastian Streich
Nika Layzell
Paul Adenot
Emilio Cobos Álvarez
Bogdan Tara
John Dai
Alphan Chen
Valentin Gosu
shindli
Andre Natal
Mihai Alexandru Michis
Jim Porter
Brendan Dahl
Sean Feng
Jonathan Kingston
Cosmin Sabou
Oana Pop Rus
Sylvestre Ledru
Ehsan Akhgari
Jan de Mooij
David Major
Jan Varga
Masayuki Nakano
Ryan VanderMeulen
Edgar Chen
Alex Chronopoulos
Abimbola Olaitan
thomasmo
Dorel Luca
Frederic Wang
Olli Pettay
Simon Giesecke
Srujana Peddinti
David Parks
Andrew McCreight
Gijs Kruitbosch