In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
`GeckoProcessManager.buildLogMsg` requires a successful bind to construct its
message, but its only remaining callsite is only invoked when a bind fails,
so it blows up.
This patch eliminates `buildLogMsg` and just changes the callsite to use
a string literal.
Differential Revision: https://phabricator.services.mozilla.com/D76086
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
* We modify connection management such that we now use more specific connection
types for {content, non-content, socket process} connections.
* We attach a native counterpart to the `GeckoProcessManager.ConnectionManager`
instance that listens for app foreground, app background, and when the
socket process is enabled, network state events.
* On app background, all non-content processes are assigned BACKGROUND priority.
Even though backgrounding the app will cause Android to drop all child
processes' priority regardless of our priority settings, we still do this as
to indicate to Android that these processes are relatively less important
than our parent process.
* When the socket process is enabled, we drop its priority when we detect that
we have no network connectivity. Note that the network management code does
the Right Thing if network connectivity changes while our app was in the
background: we receive the network state change event once we return to
foreground, therefore we do not need to do any special handling ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D74478
I'm wondering whether Gecko's response to noticing that the child process was
killed is causing some notifications on the launcher thread to arrive out of
order from others. Removing the kill since we can just let Android handle
process termination.
Differential Revision: https://phabricator.services.mozilla.com/D75416
Since this is so common, let's reserve the `AssertionError` for debug builds.
In non-debug builds we will throw a `ServiceAllocator.BindException` which
will be caught and used for completing the bind promise.
GeckoProcessManager will retry unbinding and restarting the process, which
hopefully will mitigate the problem.
We also make some improvements to exception handling hygeine.
Differential Revision: https://phabricator.services.mozilla.com/D75415
Currently `unbind()` is more or less synchronous, but since those semantics may
change in the future, for the sake of cleanliness we should ensure that our
reaction is linked to `unbindResult`.
Differential Revision: https://phabricator.services.mozilla.com/D75414
In bug 1470348 we started to detach all SurfaceTextures from the
current GL context in CompositorOGL::Pause(). This was required for
VR, so that when the VR presentation was entered the SurfaceTextures
could be attached to the VR context instead.
When RenderCompositorEGL was implemented for webrender, we copied the
call to detach from CompositorOGL. However, due to extra complexity in
webrender's threading model, this is causing assertion failures.
VR no longer relies upon the SurfaceTextures being detached when the
compositor is paused, as it now uses its own SurfaceTexture
set. Therefore we can remove the detach call from both
CompositorOGL::Pause and RenderCompositorEGL::Pause.
Differential Revision: https://phabricator.services.mozilla.com/D74832
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
