Implements showing a "Paste" popup at the last mouse position (which
overlapped the browser window) when a certain custom event is received.
Creating and dispatchting that event is implemented in one of the
following parts.
Differential Revision: https://phabricator.services.mozilla.com/D135333
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
This is currently effectively just a helper around the existing
properties. Theoretically we could streamline things here in the future
by managing primary content entirely based on BrowsingContext rather
than docshell, but there's enough complexity there right now with other
properties like updating properties on content shells as they're
attached, that it's probably not worth trying to unify right now,
especially considering the low number of consumers.
Differential Revision: https://phabricator.services.mozilla.com/D146495
Content processes can provide screen coordinates in e.g. window objects and events without waiting for the proper client-to-screen transforms to be given to them from the parent process. This poses a problem for tests that want to check the screen coordinates, so we add SpecialPowers.ContentTransformsReceived() to allow content processes to wait for these transforms.
Differential Revision: https://phabricator.services.mozilla.com/D144742
Fenix's Picture-In-Picture uses full screen mode. So it isn't same as Firefox
Desktop. When exiting full screen, Fenix's window may not same as before
entering full screen.
When this occurs,
1. When device is portrait orientation, user changes to full screen by content
script.
2. Fenix enters to full screen then orientation is changed to landscape.
3. User changes that device is changed to landscape by hand.
4. Fenix enters PiP mode. Android (Home screen) change to portrait orientation.
Then PiP window keeps landscape orientation.
5. When exiting PiP, full screen will be exited.
6. Device is landscape (by Step 3.), so Fenix window is landscape. But Gecko
restores 1.'s viewport by `nsIDOMWindowUtils.exitFullScreen`. So viewport
becomes portrait orientation size even if window is landscape orientation.
For PiP mode, although nsIDOMWindowUtils.exitFullScreen is used, it doesn't
consider this situation. So I would like to add non-restore option for it.
Differential Revision: https://phabricator.services.mozilla.com/D143992
Orientation lock allows on full screen state only now. Then if exiting full
screen, orientation lock is unlocked without `screen.orientation.unlock` call.
Although we store orientation lock state in browsing context, we don't clear
when exiting full screen. So when current content is re-activated by switching
tab etc, we try to apply orientation lock state from browsing context
unfortunately.
So we should clear this state when exiting full screen even if `unlock` isn't
called.
Differential Revision: https://phabricator.services.mozilla.com/D142938
Otherwise we can return without the widget even seeing the event. This is how other test functions are implemented.
We need this to make the test in bug 1757928 pass.
Differential Revision: https://phabricator.services.mozilla.com/D142943
Prior behavior for active tabs in an inactive app would have the process priority oom score of 15. Now it's set to a higher priority oom score of 11. This will increase priority for recently used tabs on apps and prevent Android from unloading them.
Differential Revision: https://phabricator.services.mozilla.com/D142386
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Chrome code should be able to rely on CSS pixel * devicePixelRatio =
device pixel.
Chrome code that cares about the override should use
BrowsingContext.overrideDPPX. We were exposing the no-override value in
WindowUtils but that's unneeded now.
Differential Revision: https://phabricator.services.mozilla.com/D141323
This API essentially reports whether the refresh driver is actively consuming
CPU. This is intended for use in regression tests for bugs about the refresh
driver needlessly cycling.
Differential Revision: https://phabricator.services.mozilla.com/D139218
This API essentially reports whether the refresh driver is actively consuming
CPU. This is intended for use in regression tests for bugs about the refresh
driver needlessly cycling.
Differential Revision: https://phabricator.services.mozilla.com/D139218
This API essentially reports whether the refresh driver is actively consuming
CPU. This is intended for use in regression tests for bugs about the refresh
driver needlessly cycling.
Differential Revision: https://phabricator.services.mozilla.com/D139218
Unfortunately, it cannot has `Maybe` because of used by a union. Therefore,
it needs to manage with `bool` members of whether it's initialized with or
without error and whether it has a range.
Note that this changes `nsITextInputProcessorCallback.idl` which is currently
only for automated tests too. The new behavior will be tested by the last
patch in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D137424
For all purposes, this is the same as devicePixelRatio. It was meant to
skip the resistFingerprinting check the devicePixelRatio getter does,
but we do that now using CallerType in WebIDL, so if we cared about that
for these tests (which we don't) we could just do
SpecialPowers.wrap(window).devicePixelRatio.
As a follow-up we could move the NoOverride to window for symmetry. But
it's only used by devtools touch simulation so not sure if worth it.
Differential Revision: https://phabricator.services.mozilla.com/D138021
Extensions are using getComputedStyle(body).backgroundColor, which is
wrong at multiple levels.
The one that matters for this bug is that it is not color-scheme aware.
Depends on D133770
Differential Revision: https://phabricator.services.mozilla.com/D133771
This patch includes a set of changes to the ServiceWorker internals to introduce a new
nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals
to request an active background service worker to be spawned (if it is not yet) in response to
a WebExtension API event.
The new method gets as parameters:
- the scope URL for the extension background service worker to spawn
- WebExtensions API namespace and API event name which we are going to spawn an active worker for
and return a promise which would be:
- rejected if the worker could not be spawned
- resolved to a boolean if the worker was spawned successfully (or already running)
The value of the boolean value resolved is meant to represent if the worker did actually
have any listener subscribed for the given WebExtensions API event listener
(which the WebExtensions internals may then use to decide if it is worth to send that event
to be handled by the worker script or not).
In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions
API event was subscribed syncronously when the worker was being loaded is not implemented yet
and it is always returning false (a proposed implementation for that method is going to be
added in a separate patch part of this same bugzilla issue).
A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch
(attached to this bugzilla issue as the child revision for this one).
Differential Revision: https://phabricator.services.mozilla.com/D130756
It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
This patch introduces a new getRegistrationForAddonPrincipal to nsIServiceWorkerManager.
This method is similar to the existing getRegistrationForPrincipal but:
- similarly to registerForAddonPrincipal it only gets the extension principal as its only
input parameter.
- unlike getRegistrationForPrincipal, it doesn't throw if the registration has not been found
(e.g. because it was already unregistered when the method was called).
Differential Revision: https://phabricator.services.mozilla.com/D124702
This patch introduces a new getRegistrationForAddonPrincipal to nsIServiceWorkerManager.
This method is similar to the existing getRegistrationForPrincipal but:
- similarly to registerForAddonPrincipal it only gets the extension principal as its only
input parameter.
- unlike getRegistrationForPrincipal, it doesn't throw if the registration has not been found
(e.g. because it was already unregistered when the method was called).
Differential Revision: https://phabricator.services.mozilla.com/D124702
For making it possible to check whether an expected node is observed by
`IMEContentObserver` or not in mochitest, the following patches need this API.
Differential Revision: https://phabricator.services.mozilla.com/D127610
this.browser in toolkit/actors/ControllersParent.jsm is the top level browser, ie the browser holding the root content document. So the conversion that happens in that file converts the coordinates to be relative to the root content document, but they need to be relative to the root of whichever child process we are sending the event to.
The best way I found out how to do this was to pass the coords down to the child process still relative to the parent process widget and then in the child process use the child to parent transform matrix to make them relative to the root widget in the child process.
I needed a new nsIDOMWindowUtils functions because I don't think there is anything existing to do this.
Differential Revision: https://phabricator.services.mozilla.com/D126861
Mirko Brodesser
Emilio Cobos Álvarez
Masayuki Nakano
Frederik Braun
Iulian Moraru
Nika Layzell
David Parks
Makoto Kato
Timothy Nikkel
Cathy Lu
Mike Conley
Butkovits Atila
Hiroyuki Ikezoe
Cristian Tuns
Peter Van der Beken
Daniel Holbert
Marian-Vasile Laza
Molly Howell
Kagami Sascha Rosylight
Luca Greco
Marcos Cáceres
Narcis Beleuzu
sotaro
Anny Gakhokidze