After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
Things that were broken:
- prompts become unreadable when using dark-background lwthemes, because they
keep the window text-shadow (due to the namespace change of tabmodalprompt)
- prompts with long text without word-wrap possibilities
(e.g. `alert("x".repeat(1000))`) cause the text to escape its container.
Differential Revision: https://phabricator.services.mozilla.com/D73131
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
We don't access HasStoragePermission across process, so we don't need to
store the permission in WindowContext.
After this patch, HasStoragePermission will only be stored in the
channel's LoadInfo, which is set when a channel is created in the parent
and it won't be updated.
Depends on D71985
Differential Revision: https://phabricator.services.mozilla.com/D72305
Both the deprecated `Screen.lockOrientation` and replacement
`ScreenOrientation.lock` APIs have been updated to make use of a new
`OrientationLock` field on the `BrowsingContext`. This replaces the
storage and use of APIs for this on the root docshell.
In the non fission case things should behave the same, as pending
promises for previous calls to `Screen.lockOrientation` will still be
cancelled in process. If there are `BrowsingContext`s in other
processes though, IPC will be sent to the parent, and then each other
child to cancel them. This should be spec compliant as the spec is
already racy with regards to multiple `lockOrientation` calls.
This new implementation has a little extra IPC than the optimal
implementation would since the root `BrowsingContext`s
`OrientationLock` is set using the normal `SyncedContext` machinery,
rather than combining the `AbortOtherOrientationPendingPromises`
message for a single message.
This commit fixes both Bug 1597413 and Bug 1597443.
Differential Revision: https://phabricator.services.mozilla.com/D70416
In BrowsingContext::SetDocShell(), we indicate that any remote outer window
proxies need to be cleaned up, if we've transitioned from a remote window
proxy to a local one. However, we don't actually do the cleanup until
nsGlobalWindowOuter::SetNewDocument(), so don't assert if we find remote
window proxies when we're in between these two periods.
Also includes a formatting fix by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D72251
Due to the refactored code,
browser/base/content/test/performance/browser_preferences_usage.js started
reporting more accesses to browser.cache.check_doc_frequency preference.
Differential Revision: https://phabricator.services.mozilla.com/D68319
This was previously true, since we only used ResumeRedirectedLoad with a brand new docshell. This bug adds code for using it with existing docshells, which can have any Document (and associated timing object) loaded in them.
Differential Revision: https://phabricator.services.mozilla.com/D67097
Same process origin changes are handled by the docshell, which detects this during AsyncOnChannelRedirect and clears the mixed content permission.
Process switches load in a fresh docshell, so we need to make sure we appropriately set or clear the mixed content permission.
Differential Revision: https://phabricator.services.mozilla.com/D67095
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
stundets
Christoph Kerschbaumer
Nika Layzell
Matt Woodrow
Emilio Cobos Álvarez
Dorel Luca
Gijs Kruitbosch
Dimi Lee
Mike Conley
Csoregi Natalia
Jean-Yves Avenard
Steven MacLeod
Andrew McCreight
Dan Glastonbury
Andreas Farre
Sylvestre Ledru
Simon Giesecke
Cosmin Sabou