Rather that setting the property bag on both the child and parent from the docshell; we first set it on the parent instead, and once the redirect (or process switch) has completed we carry that bag across.
Differential Revision: https://phabricator.services.mozilla.com/D53924
--HG--
extra : moz-landing-system : lando
Looks like this can sometimes fail with moz-extension URIs, so we shouldn't crash
Differential Revision: https://phabricator.services.mozilla.com/D54249
--HG--
extra : moz-landing-system : lando
Without DocumentChannel, nsExtProtocolChannel::OpenURL calls into nsExternalHelperAppService::LoadURI in the content process.
We then manually forward this to the parent process over PContent, create a RemoteWindowContext around the browser parent, and then call LoadURI again.
With DocumemntChannel, the nsExtProtocolChannel already lives in the parent, so we just need to provide a RemoteWindowContext directly (that the code accesses via GetInterface on the callbacks).
Differential Revision: https://phabricator.services.mozilla.com/D54247
--HG--
extra : moz-landing-system : lando
It's a better name, and will avoid confusion when I add other stylesheet caches
outside of the CSS loader.
Depends on D54556
Differential Revision: https://phabricator.services.mozilla.com/D54557
--HG--
rename : layout/style/nsLayoutStylesheetCache.cpp => layout/style/GlobalStyleSheetCache.cpp
rename : layout/style/nsLayoutStylesheetCache.h => layout/style/GlobalStyleSheetCache.h
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
The dynamic toolbar transition doesn't affect on background tabs since to
switch tabs the dynamic toolbar should be restored to its original state (i.e.,
completely visible state).
Differential Revision: https://phabricator.services.mozilla.com/D52336
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
These two functions both have a large number of arguments that are largely identical (and ones missing from the PContent one are mostly oversights).
Unifying both to take a single argument and return the same result means we can unify the serialization and return value (promise) handling.
Differential Revision: https://phabricator.services.mozilla.com/D53382
--HG--
extra : moz-landing-system : lando
This involves two new IPC messages (both async) to propagate the change in
compositor options (of which APZ enablement is one) from the GPU process to
the parent process (via PCompositorBridge) and on to the content process
(via PBrowser).
The support is only partial, in that going from non-APZ to APZ is only
supported if APZ was enabled at the time the window was created.
Depends on D51467
Differential Revision: https://phabricator.services.mozilla.com/D51468
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
Preventing RemoteWorkerService from existing in "web COOP+COEP" content
processes prevents Shared/ServiceWorkers from being spawned in them because there
won't be an associated RemoteWorkerServiceParent that registers with the parent
process RemoteWorkerManager.
Differential Revision: https://phabricator.services.mozilla.com/D50815
--HG--
extra : moz-landing-system : lando
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
--HG--
extra : moz-landing-system : lando
And deliver the value to the top content pres context, but it's not used in
this commit. The value will be used in the next commit.
One caveat is that areas covered by the dynamic toolbar will be outside
of the content area, which means implementers of GeckoView needs to call
setVerticalClipping with _negative_ values.
Depends on D50416
Differential Revision: https://phabricator.services.mozilla.com/D50417
--HG--
extra : moz-landing-system : lando
This additionally turns on dom.ipc.processHangMonitor on non-m-c consumers of gecko, as well as turning off dom.ipc.reportProcessHangs on debug geckoview.
Differential Revision: https://phabricator.services.mozilla.com/D52699
--HG--
extra : moz-landing-system : lando
ContentParent::GetNewOrUsedBrowserProcess can end up returning a
content parent that is in the middle of shutting down if the
nsIContentProcessProvider implementation threw an error because we'd
fall back to MinTabSelect(), which didn't exclude content parents that
were being shutdown. This patch fixes that.
The reason that the existing implementations of
nsIContentProcessProviders fail is that the array that is passed to
them can contain null entries which the code does not expect. I'll fix
that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D52774
--HG--
extra : moz-landing-system : lando
This also converts MaybeCloseWindowHelper, and results in the window close operations being always run in the parent (even without DocumentChannel).
Differential Revision: https://phabricator.services.mozilla.com/D49528
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
Set the environment variable OS_ACTIVITY_MODE=disable on sandboxed Mac child processes.
Differential Revision: https://phabricator.services.mozilla.com/D49972
--HG--
extra : moz-landing-system : lando
Instead of letting the outer window to process `MediaControlActions`, it would be better to handle those actions all in `MediaActionHandler`.
Differential Revision: https://phabricator.services.mozilla.com/D51029
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
The reason of the crash is, the window may have already been destroyed and
`PuppetWidget::mBrowserChild` was set to `nullptr` when synthesizing key event.
This patch makes `PuppetWidget::GetEditCommands()` check whether it's `nullptr`
and returns whether it's succeeded or not. Therefore, `TextInputProcessor`
can throw exception in such case.
Differential Revision: https://phabricator.services.mozilla.com/D52308
--HG--
extra : moz-landing-system : lando
ExpandUnveilPath() takes care of expanding potentially
environment-specific XDG_DATA/CONFIG/CACHE_HOME dirs.
The unveil config files lists the allowed paths & modes.
'disable' in the files will disable the corresponding pledge/unveil
syscall.
Differential Revision: https://phabricator.services.mozilla.com/D51387
--HG--
extra : moz-landing-system : lando
this way, preferences cant be modified by an extension, and they're
locked down in root-owned files.
Pledge promises files consist of a promise by line, are read first from
/etc/MOZ_APP_NAME/pledge.${processtype} (allowing overriding by a local
root if needed), and if not found
/usr/local/lib/MOZ_APP_NAME/browser/defaults/preferences is used, which
is where the OpenBSD packaging system will install the defaults.
Differential Revision: https://phabricator.services.mozilla.com/D51385
--HG--
extra : moz-landing-system : lando
Prior to this patch, users entering javascript: URLs in the location bar
(e.g. via a bookmark) would trigger the cancel content JS path for the page
they were on, potentially breaking the site. Since javascript: URLs
(generally) don't navigate to a new page, we should avoid canceling the
current page's JS.
Differential Revision: https://phabricator.services.mozilla.com/D51951
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
Also, enable it for the extensions test directory. Without this pref,
it gets frequent intermittent leaks and shutdown hangs when Fission is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D51752
--HG--
extra : moz-landing-system : lando
Right now, this constant has an equal sign in it. I want to use it in
C++ without the equal sign in the next patch. So, for consistency,
move the equal sign to the places that use this constant. Also, add
the constant to C++.
Differential Revision: https://phabricator.services.mozilla.com/D51751
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
The Geolocation API specification renamed the following interfaces and removed the [NoInterfaceObject] annotation so that these types are now exposed to script:
* Coordinates -> GeolocationCoordinates
* Position -> GeolocationPosition
* PositionError -> GeolocationPositionError
This is done in response to an effort to remove the [NoInterfaceObject]
annotation from WebIDL.
Additionally, the following interfaces are now only exposed in Secure Contexts:
* GeolocationCoordinates
* GeolocationPosition
Differential Revision: https://phabricator.services.mozilla.com/D51972
--HG--
rename : dom/geolocation/PositionError.cpp => dom/geolocation/GeolocationPositionError.cpp
rename : dom/geolocation/PositionError.h => dom/geolocation/GeolocationPositionError.h
rename : dom/webidl/Coordinates.webidl => dom/webidl/GeolocationCoordinates.webidl
rename : dom/webidl/Position.webidl => dom/webidl/GeolocationPosition.webidl
rename : dom/webidl/PositionError.webidl => dom/webidl/GeolocationPositionError.webidl
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
Behind a pref to ensure that we can turn this off pretty easily if it has perf
impact.
I want to leave the repainting stuff to another bug to land separately, to track
potential (though I hope not!) perf regressions more easily.
Differential Revision: https://phabricator.services.mozilla.com/D50704
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
LaunchRDDProcess() and CreateContentBridge() create a sync creation. Merge the
functions into one function. Keep the IPDL messaging async to avoid adding a
exception for the message being sync.
Differential Revision: https://phabricator.services.mozilla.com/D50400
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
LaunchRDDProcess() and CreateContentBridge() create a sync creation. Merge the
functions into one function. Keep the IPDL messaging async to avoid adding a
exception for the message being sync.
Differential Revision: https://phabricator.services.mozilla.com/D50400
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D49840
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
This event is useful for tests that resize the RDM pane and need to
know when all resolution adjusting effects are complete.
Differential Revision: https://phabricator.services.mozilla.com/D47364
--HG--
extra : moz-landing-system : lando
In this patch, we add the propagation of the first party domain through
the tabContext while creating OOP browsers. In the window.open() case,
we will propagate the first party domain from the opener's browser parent.
And in the frame case, we will propagate it from the manager of the
browserBridgeParent of the OOP frame.
Differential Revision: https://phabricator.services.mozilla.com/D49886
--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
* 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
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
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
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This is useful in part 3, where the initialization will need to be called from
multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D47308
--HG--
extra : moz-landing-system : lando
This flag is only meant for window.open() stuff, so not relevant to iframes at
all.
This preserves the current fission behavior (which is quite broken) of always
showing scrollbars.
The way to control scrollbars for iframes (the scrolling attribute) is not
handled at all for Fission, I filed a bug and left a few FIXMEs.
Differential Revision: https://phabricator.services.mozilla.com/D49292
--HG--
extra : moz-landing-system : lando
Currently when checking if a window supports protected media it's up to the
caller interacting with a BrowserChild to check if a response is already
cached, to perform the check if needed, and to then set the cached response if a
call was made. This patch moves that logic internal to Browser child so that
callers need to only worry about interacting with a single function.
Differential Revision: https://phabricator.services.mozilla.com/D48585
--HG--
extra : moz-landing-system : lando
Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
It doesn't have any useful effect given the way Fission chooses processes, and
complicates the window.open logic in ways that are hard to maintain and cause
problems.
Differential Revision: https://phabricator.services.mozilla.com/D48749
--HG--
extra : moz-landing-system : lando
See the first patch's commit message to learn why we had to change the
PageInformation's IDs to BrowsingContextID and InnerWindowID.
Previously we were registering profiler PageInformation in the nsDocShell
methods. That was not the correct place to handle page loads correctly. That's
why we had to move the registration to WindowGlobalChild::SetDocumentURI and
WindowGlobalChild::ActorDestroy. In those functions we are sure that each
document URIs will come here only once.
Differential Revision: https://phabricator.services.mozilla.com/D47066
--HG--
extra : moz-landing-system : lando
Web Share base implementation just of DOM stuff - working together with @saschanaz.
@Baku, we would greatly appreciate your review.
-Nika, as she is traveling.
Differential Revision: https://phabricator.services.mozilla.com/D44598
--HG--
extra : moz-landing-system : lando
Previously we assumed that we could trust the `OnLocationChange`,
`OnStateChange`, and `OnSecurityChange` IPC messages from the BrowserChild to
BrowserParent to always contain their optional data if the message was
top-level. However, if a content process becomes compromised, this could be
used to DOS the parent process by maliciously sending these messages to the
parent process with invalid data.
Now we explicitly check that the data is valid before derefing.
Differential Revision: https://phabricator.services.mozilla.com/D48423
--HG--
extra : moz-landing-system : lando
This just splits out the InputBuffer and OutputBuffer helper classes
to make it cleaner for the StartupCache to include them.
Differential Revision: https://phabricator.services.mozilla.com/D34651
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This is useful in part 3, where the initialization will need to be called from
multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D47308
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This is useful in part 3, where the initialization will need to be called from
multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D47308
--HG--
extra : moz-landing-system : lando
This patch does the following to support matching a whitelisted URI when
its domain is eTLD+1:
1. add an URIType to indicate whether a URI is generated by
UrlClassifierCommoon::CreatePairwiseWhiteListURI(), which crafts a
whitelist URL like "toplevel.page/?resource=third.party.domain"
2. call LookupCache::GetLookupWhitelistFragments() if URIType is
nsIUrlClassifierFeature::pairwiseWhitelistedURI before initiating
a lookup.
3. implement LookupCache::GetLookupWhitelistFragments() which creates
an additional fragment by removing the leading component of
third.party.domain
Differential Revision: https://phabricator.services.mozilla.com/D47212
--HG--
extra : moz-landing-system : lando
This just splits out the InputBuffer and OutputBuffer helper classes
to make it cleaner for the StartupCache to include them.
Differential Revision: https://phabricator.services.mozilla.com/D34651
--HG--
extra : moz-landing-system : lando
It's useless if the tab is already visible (i.e., has renderLayers=true), per
the previous patches, and that's the only point at which it gets called.
Differential Revision: https://phabricator.services.mozilla.com/D47131
--HG--
extra : moz-landing-system : lando
aForceRepaint wasn't doing what it claimed to do at all, as we've recently
learned. In current mozilla-central:
* All those arguments ended up in a RecvRenderLayers with aForceRepaint = true
(so far so good, that's expected).
* But it was ignored (so that aForceRepaint is always true to calls to
MakeVisible) from UpdateVisibility:
https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/ipc/BrowserChild.cpp#2523
* Plus that argument only does anything useful on current central if we get to
the end of MakeVisible(true). And MakeVisible() early returns if already
visible.
So all in all this seems somewhat useless, and nobody has complained about such
a thing in a long time.
It seemed to do what it promised when it was introduced in
https://hg.mozilla.org/mozilla-central/rev/27f6f789b194, but it seems the
refactoring in https://hg.mozilla.org/mozilla-central/rev/4df5fa6fa785 broke it.
I think the new setup is somewhat easier to reason about, and nobody seems to be
missing that.
I'll try to remove the forceRepaint() call itself on a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D47127
--HG--
extra : moz-landing-system : lando
That is, for fission iframes. For top level stuff we rely on the tab switcher
going through SetDocShellIsActive and such.
See the expanded comment as for why. Ideally we could simplify this further by
not making RecvRenderLayers update the visibility (which spins the refresh
driver and such).
It's a bit suspect because it's very easy to get to an inconsistent state if the
browser chrome does something wrong.
I'll try to do that, but for now this should improve the fission situation
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D46706
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
This fixes both our failure to register load blockers for remote frames and
our failure to keep the load event blocked during frameloader rebuilding on
remoteness change.
Differential Revision: https://phabricator.services.mozilla.com/D46503
--HG--
extra : source : dff7756afe8ede1e03d775ec4999d4807d82c1da
extra : histedit_source : b02eae2b652683ef17be3e0ff6a908b4bec311f5%2Cc62c8e5e4ca066f8f526a81a9aae0feeb84326a5
DocumentChannel doesn't use the REDIRECT_INTERNAL flag when replacing itself with a real channel if there has been a real redirect handled in the parent.
This is so that the docshell knows about the URI change, and to add history entries.
The timing data however always wanted to be treated as an internal redirect, so that we don't record a new 'redirectEnd' at the time of the switch.
This adds a new parameter to ConfigureReplacementChannel so that we can more accurately describe the behaviour we need.
Differential Revision: https://phabricator.services.mozilla.com/D45150
--HG--
extra : moz-landing-system : lando
* The test first asserts that we can actually load iframes in separate subprocesses
* The test now loads in a new tab rather than a new window
* The test no longer uses the "fission" attribute
* The test avoids the BrowsingContext.get pattern, in favour of just passing the
BrowsingContext from one actor to the other directly.
Differential Revision: https://phabricator.services.mozilla.com/D45744
--HG--
extra : moz-landing-system : lando
This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
This class allows to encapsulate all the information required in order to create a new HttpChannel object following a redirect.
Differential Revision: https://phabricator.services.mozilla.com/D40959
Sylvestre Ledru
Brindusan Cristian
Matt Woodrow
Jean-Yves Avenard
Coroiu Cristina
Emma Malysz
Emilio Cobos Álvarez
Andrew McCreight
Andreea Pavel
Doug Thayer
Hiroyuki Ikezoe
Narcis Beleuzu
Perry Jiang
Anny Gakhokidze
Botond Ballo
Micah Tigley
Ehsan Akhgari
Noemi Erli
Gurzau Raul
Gijs Kruitbosch
Jonathan Kew
Sid Vishnoi
Andreas Farre
Bogdan Tara
Valentin Gosu
Haik Aftandilian
alwu
Masayuki Nakano
joshua stein
Jim Porter
James Teh
Daniel Varga
thomasmo
Sebastian Hengst
Kashav Madan
Brendan Dahl
Cosmin Sabou
Mihai Alexandru Michis
Ciure Andrei
Peter Van der Beken
Dorel Luca
Dan Glastonbury
Razvan Maries
Nihanth Subramanya
Oana Pop Rus
Tom Tung
Gabriele Svelto
Edgar Chen
Brad Werth
Csoregi Natalia
Tim Huang
Thomas Nguyen
Nika Layzell
shindli
Geoff Brown
Srujana Peddinti
Marcos Cáceres
Bryce Seager van Dyk
Paul Adenot
Marco Bonardo
Kris Maglione
Nazım Can Altınova
Brian Hackett
Marcos Cáceres
Barret Rennie
Brian Grinstead
DimiL
Tom Tung
Junior Hsu
Agi Sferro
arthur.iakab
Jonathan Watt
Mike Conley
John Dai
Boris Zbarsky
Paul Zuehlcke
Alphan Chen
Garvan Keeley