This makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
The SpinEventLoopUntilOrShutdown is interrupted in the main process only at stage "xpcom-shutdown", which is too late. In a content process instead we interrupt it early enough, at "content-child-will-shutdown".
This patch removes the current observer logic in nsThreadManager in favor of a current shutdown phase state machinery in AppShutdown and renames SpinEventLoopUntilOrShutdown to SpinEventLoopUntilOrQuit. It also ensures that SpinEventLoopUntilOrQuit breaks early (at "quit-application" in the main process).
For a further possible cleanup around shutdown state in child and parent process please refer to bug 1697745.
We have no automated test for this edge case, but we have diagnostic telemetry that will tell us if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D107619
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
We only use the contentBlockingAllowListPrincipal for excluding sites from content
blocking for top level documents. We don't need it in the content process and should
not compute it for every document.
Differential Revision: https://phabricator.services.mozilla.com/D100781
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
Make it a synced field on the top browsing context. This handling the
propagation right and is much simpler.
This should fix cases where we don't look at the top level docshell to
figure out if we should suspend media.
Differential Revision: https://phabricator.services.mozilla.com/D94878
D89390 introduced a new mechanism which avoids tab with playing audio from being suspended when they are in background. However, it causes some unsatisfying regression such as bug 1670066 and bug 1670069.
In addition, according to what D89390 did, we change tab's docshell active state, which would also affect visibility event [1], and doing that would make tab always visible that would probably cause some bad effect. IIRC, some API like canvas would slow down its performance when it's in background in order to reduce the power consumption.
Therfore, reverting those change first and would use another way to fix the problem.
Differential Revision: https://phabricator.services.mozilla.com/D93444
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
When session history is in the parent we can read state directly from it,
instead of waiting for the child process to send a message with the updated
state. The old mechanism (BrowserParent::RecvOnLocationChange calling
UpdateWebNavigationForLocationChange) is still needed for when session history
in the parent is turned off. We'll remove it eventually, once session history in
the parent sticks.
Differential Revision: https://phabricator.services.mozilla.com/D89418
The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D85653
