Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
In bug 1773342, I made OS text zoom behave like layout full zoom on all
pages (including the main browser page).
This means that getting CSS pixels from the browser page and turning
them to LayoutDevice pixels by multiplying by GetDefaultScale() isn't
right.
However, the caller already has the right device pixel values, so just
use them.
Differential Revision: https://phabricator.services.mozilla.com/D149026
The old calculation based on device pixels _might_ be correct, but it sure was
sketchy. This is more straight-forward / easier to follow.
Depends on D139777
Differential Revision: https://phabricator.services.mozilla.com/D139778
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138035
Differential Revision: https://phabricator.services.mozilla.com/D138036
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138035
Differential Revision: https://phabricator.services.mozilla.com/D138036
screenForRect takes screen coordinates (device pixels, for our purpose here).
However screenX / screenY are in CSS pixels, so we need to convert them to the
right coordinate space before looking up the screen.
Differential Revision: https://phabricator.services.mozilla.com/D137895
I opted to add another argument for this to browser-custom-element, rather than
trying to change the caller interface too much.
Differential Revision: https://phabricator.services.mozilla.com/D130118
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
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
