Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Previously, we would only send web progress events from the toplevel
BrowserParent, as other frames would never have the browser-child.js framescript
loaded in them, and so would never start sending events. This change moves the
decision to begin sending events into BrowserChild itself around the same time
as it would've happened previously with the framescript.
This new callsite should still avoid sending events for the creation of the
initial about:blank document in the BrowserChild, while not skipping any other
events, as before.
Differential Revision: https://phabricator.services.mozilla.com/D105558
This change allows associating individual web progress events with which frame
they originate from, rather than only recording the `isToplevel` information as
we were before, which is necessary in order to use the OnLocationChange events
from content to track the current URI on CanonicalBrowsingContext.
Due to events in ContentChild being filtered through nsBrowserStatusFilter, some
of the callbacks will never be passed nsIRequest or nsIWebProgress pointers, and
this patch also simplifies them by removing information which is not necessary
from the IPC message.
Finally, this patch adds a number of checks to the relevant Recv callbacks in
the parent process which help ensure that it does not accept web progress events
from a content process which is no longer hosting the target BrowsingContext.
This may allow for us to stop manually suspending web progress events on process
switches, as these checks will handle this automatically based on the existing
BrowsingContext and WindowContext objects.
Differential Revision: https://phabricator.services.mozilla.com/D105556
Inversed logic has been proven to be more difficult to read,
so use the simple positive variant.
Also add a simple sanity check for `WAYLAND_DISPLAY` so if people
set `MOZ_ENABLE_WAYLAND` in a X11 session don't get undesired behavior.
While on it, change a check for `XDG_SESSION_TYPE` to also use
`WAYLAND_DISPLAY`, improving behavior when launching FF from a TTY
or a TTY-launched session (e.g. via `weston-launch`).
`WAYLAND_DISPLAY` and `DISPLAY` are not expected to be set if
no Wayland or X11 server is available, so using them makes us behave
more predictable.
Differential Revision: https://phabricator.services.mozilla.com/D106726
If we don't do this, then just moving the mouse over a window experiencing a
slow script will cause it to show the notification. We could try to
deserialize the message inside nsContentUtils::IsMessageCriticalInputEvent, but
that seems overcomplicated compared to just adding a new message which proxies
to the original message handlers.
Differential Revision: https://phabricator.services.mozilla.com/D106016
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
If we don't do this, then just moving the mouse over a window experiencing a
slow script will cause it to show the notification. We could try to
deserialize the message inside nsContentUtils::IsMessageCriticalInputEvent, but
that seems overcomplicated compared to just adding a new message which proxies
to the original message handlers.
Differential Revision: https://phabricator.services.mozilla.com/D106016
If we don't do this, then just moving the mouse over a window experiencing a
slow script will cause it to show the notification. We could try to
deserialize the message inside nsContentUtils::IsMessageCriticalInputEvent, but
that seems overcomplicated compared to just adding a new message which proxies
to the original message handlers.
Differential Revision: https://phabricator.services.mozilla.com/D106016
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
I flagged this as sketchy before (though it was trying to preserve
existing behavior).
However now that that state propagates to the parent process and races
with the state that the parent process reads, it started causing
correctness issues.
Just remove this line, it shouldn't be needed. I'm not sure how to write
a test for this, unfortunately :(
Differential Revision: https://phabricator.services.mozilla.com/D100971
This fixes a bunch of regressions:
- a wrong calculation in `GetIdleDeadlineHint()`, leading to pageload
regressions.
- in certain situations we'd use `StartupRefreshDriverTimer` instead
of `VsyncRefreshDriverTimer` when initializing timers early
- unnecessary use of `BrowserChild` on backends that don't opt for
per-browser-child vsync - i.e. all but Wayland.
This is partly done by reverting to pre-1645528 behaviour, although
with some code simplifications.
FTR: I also played with some more radical changes, but given the
complexity of the code involved I found the regression potential too
big. Thus this is the most conservative solution I could come up with.
Differential Revision: https://phabricator.services.mozilla.com/D100471
This fixes a bunch of regressions:
- a wrong calculation in `GetIdleDeadlineHint()`, leading to pageload
regressions.
- in certain situations we'd use `StartupRefreshDriverTimer` instead
of `VsyncRefreshDriverTimer` when initializing timers early
- unnecessary use of `BrowserChild` on backends that don't opt for
per-browser-child vsync - i.e. all but Wayland.
This is partly done by reverting to pre-1645528 behaviour, although
with some code simplifications.
FTR: I also played with some more radical changes, but given the
complexity of the code involved I found the regression potential too
big. Thus this is the most conservative solution I could come up with.
Differential Revision: https://phabricator.services.mozilla.com/D100471
DelayedDeleteRunnable would schedule itself twice and use input priority
for the second time because it only wants to run after everything
that could possibly touch this tab. This was needed because we were
strict with IPC messages. However, this is no longer needed because
IPC messages with destroyed actors will be discarded nowadays, so
we don't have to use input priority anymore.
Another reason for making this change is that input events could be
suspended when the runnable is about to run, so we need to either
use a different priority or resume input events.
Differential Revision: https://phabricator.services.mozilla.com/D100345
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
Every synthesized mouse event for tests are important. So, they should never
be coalesced. This is required to write mochitests which synthesize `mousemove`
events via the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D99317
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Depends on D98254
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
