We enable compilation of FOG/Glean on _all_ platforms.
We disable Glean initialization and metric recording on Android (GeckoView) by respecting MOZ_GLEAN_ANDROID.
This way GeckoView just works, consumers don't need to think about it (except in tests, these need to be disabled for Android builds).
Stubbing out the metric implementations will happen in the commits after
this one.
Differential Revision: https://phabricator.services.mozilla.com/D106766
The check was a bit too general it seems. Explicitly allow moving focus
for link clicks and window.open(), which are the things we have tests
for and care about moving focus.
Differential Revision: https://phabricator.services.mozilla.com/D107039
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
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
When there is two-level nested iframe, like, a.com contains an iframe b.com,
and b.com contains an iframe c.com, when script in c.com calls window.focus()
to get the focus, we need to adjust the activeElement in a.com and b.com.
Currently, it needs to bounce IPC twice to make a.com get updated. This patch
tries to make a.com could be updated sooner, so when parent process recive the
adjustWindowFocus IPC from process of c.com, it will notify process of b.com
and a.com at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D105659
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
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 patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
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
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
First, it should be called "Lookup" rather than "Get" because it returns
DataType (rather than UserDataType), but that would still be confusing,
since as opposed to other Lookup* methods, it does not return a DataType&
(and obviously, it can't). So "Extract" seems to be a better name, cf.
mozilla::Maybe::extract.
Differential Revision: https://phabricator.services.mozilla.com/D105471
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
The telemetry is triggered either when the user is shown the tab crashed page, or when the subframe notification is displayed and the crash occurs in an active tab, or when the user switches to a tab that has a subframe crash notification displayed. The telemetry only applies the first time the tab is switched to. The unsubmitted crashes notification bar appears after 10 minutes or so and is shown in the top-most browser window, if one exists, and telemetry applies once when this occurs.
Differential Revision: https://phabricator.services.mozilla.com/D100349
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
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
That doesn't go through BrowsingContext::InternalLoad. This matches the
behavior of clicking links and the behavior of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D103720
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
Currently, we don't allow keyboard events synthesized for tests retrieve native
key bindings in content process. However, due to this, we cannot test keyboard
navigation, deleting per word, etc on Linux and macOS either with mochitest
or WPT. For making better compatibility with the other browsers, we should
write WPT more with the test driver. Therefore, we should allow keyboard
events synthesized for tests retrieve native key bindings.
On the other hand, if we make them retrieve customized keyboard shortcuts
in the environment, some developers may not be able to run tests locally without
resetting their customization. Therefore, this patch makes `NativeKeyBindings`
set "standard" shortcut keys on the platform instead of retrieving actual
shortcut key results.
If referring the default shortcut key bindings is not good thing for
WebDriver/CDP, perhaps, `TextInputProcessor` should have a new flag which can
refer customized shortcut keys even in content process. But I think that it
should be done in another bug because some edit commands are mapped forcibly
like this patch.
https://searchfox.org/mozilla-central/rev/c03e8de87cdb0ce0378c0886d3c0ce8bbf9dc44e/remote/domains/parent/Input.jsm#82-102
Differential Revision: https://phabricator.services.mozilla.com/D102877
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
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
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
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
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
We can launch the RDD process early now that it is a fully asynchronous process and doesn't block anything.
This will allow to retrieve the decoding capabilities of the RDD process right away.
Ideally, we should have been able to start the RDD process at the same time as the GPU process; however setting up the RDD sandbox is dependent of having mozilla::SandboxBroker::GeckoDependentInitialize() called first ; and it is called in the most awkward of places; so finding a place suitable for all platforms gets affected.
For now we will ensure it's been started around the time the first content process is started.
Differential Revision: https://phabricator.services.mozilla.com/D100304
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
My guess is that if Observe() gets called too early, we can receive the
message before updating the vsync source the first time, which would
trigger this crash.
With this patch, we handle it nicely and UpdateVsyncSource will
re-observe as needed.
It's not 100% clear to me if this is actually the issue (and thus
whether this patch is the right solution), since I haven't been able to
repro locally, though. There might be a more subtle race.
Differential Revision: https://phabricator.services.mozilla.com/D100501
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
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This avoids us doing the full work of ExtractData every time a new content
process is created. That work is probably not super expensive, but without
this caching it does trip up
browser/base/content/test/performance/browser_preferences_usage.js due to
looking up a non-mirrored pref.
Differential Revision: https://phabricator.services.mozilla.com/D98990
This adds a new LookAndFeel implementation, RemoteLookAndFeel, which can
be used in content processes and is supplied with all of its values by the
parent process.
Co-authored-by: Cameron McCormack <cam@mcc.id.au>
Differential Revision: https://phabricator.services.mozilla.com/D97977
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
Specifically, remove the include of StructuredCloneHolder.h from
RefMessageBodyService.h, and that of WorkerRunnable.h from PromiseWorkerProxy.h
and add other required includes instead.
Differential Revision: https://phabricator.services.mozilla.com/D94764
When a user clicks a form, the password manager popups a warning when the
form is not in a secure context. However, there is an exception when
a form is in an iframe. When both the url of the iframe and the top-level
are both local ip addresses, we consider it is safe.
This patch adds isLocalIP to WindowContext and WindowGlobalActor.webidl
so password manager can identify whether the top-level url is a local ip
address under fission.
Differential Revision: https://phabricator.services.mozilla.com/D99041
I think there could be still other issues with persist handling (or at least it could be simplified),
but this should be pretty much the minimal patch to fix the issue when
about:newtab url is changed to about:blank (without a redirect, but magical about: handling).
So we need to check persisted handling later than currently.
I'd prefer to land something like this first and then consider if there are better ways to handle
both about: url changes and proper redirects.
Depends on D93899
Differential Revision: https://phabricator.services.mozilla.com/D98871
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
Actually, our locale service doesn't use UTF-16 for locale name and it will
be ASCII. Although dictionary name of spell checker is locale/language name,
it still uses UTF-16. To use locale API, I should replace it with `ACString`.
Differential Revision: https://phabricator.services.mozilla.com/D99336
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
This avoids a problem where we receive the IPC message from the child
with updated intrinsics before an <embed> or <object> has had its frame
constructed in the parent, and drop the update.
Differential Revision: https://phabricator.services.mozilla.com/D99304
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
This was being called every time we created a ContentParent, which meant
that we'd get races with non-main-thread logging in the parent
process. This patch fixes it by only calling it once during process
startup.
The original goal was to avoid making logging noisier with process
information when e10s was not enabled, but given that e10s is the default
now, that is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D98935
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
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
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
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
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
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
Currently, when JS callers try to access certain JSWindowActors before an
actor is initialized, or after it's destroyed, we throw a generic
`NS_ERROR_INVALID_STATE_ERROR` exception without any useful information about
the failure.
This patch changes that to use `ThrowInvalidStateError`, with a message
including the property name, the actor name, and details about whether the
error occurred because the actor has not been initialized or because it has
already been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D96628
The guess in comment 3 is basically right, here's the relevant bits that
happen in that trace in order:
[content] nsFrameLoaderOwner::ChangeRemotenessCommon:
frame becomes remote for the content process.
[parent] WindowGlobalParent::SendMakeFrameLocal (mIsDocumentLoad=true)
[content] ContentChild::SendCloneDocumentTreeInto
[parent] ContentParent::RecvCloneDocumentTreeInto
[content] WindowGlobalChild::RecvMakeFrameLocal
So basically the source frame we're cloning is mid-switch-to-local:
local already from the parent process POV, but still remote for the
child.
I think ignoring the clone in this case is fine (which will make the
print iframe just about:blank).
I've decided it to handle it in ChangeRemoteness but I could also handle
it in RecvCloneDocumentTreeInto with a check like
if (cp->GetRemoteType() == GetRemoteType())
or such I think. Let me know if you'd prefer that.
Differential Revision: https://phabricator.services.mozilla.com/D97144
While pointer lock happens in a different process than pointer capturing process,
we would notify pointer capturing process to release pointer capture, and it relies
on subsequent eMouseExitFromWidget event to generate lostpointercaptre event.
So make them use the same priority to ensure the order.
Differential Revision: https://phabricator.services.mozilla.com/D95266
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
Simon Giesecke
Jan-Erik Rediger
Emilio Cobos Álvarez
Jens Stutte
Kagami Sascha Rosylight
Eitan Isaacson
Robert Mader
Olli Pettay
Mihai Alexandru Michis
Edgar Chen
Doug Thayer
Butkovits Atila
Neil Deakin
Bogdan Tara
Randell Jesup
Cosmin Sabou
Brindusan Cristian
Masayuki Nakano
Narcis Beleuzu
smolnar
Gijs Kruitbosch
alaaemad
Alexis Beingessner
Gerald Squelart
Tom Schuster
Barret Rennie
Noemi Erli
Nika Layzell
Andreea Pavel
Henri Sivonen
Christoph Kerschbaumer
Matthew Gregan
Kris Maglione
Tom Ritter
Csoregi Natalia
Markus Stange
Dorel Luca
Mats Palmgren
Masatoshi Kimura
Paul Zuehlcke
Andreas Farre
Kartik Gautam
Sylvestre Ledru
Jean-Yves Avenard
Jonathan Kew
Razvan Maries
Sean Feng
Cameron McCormack
Jed Davis
Agi Sferro
Peter Van der Beken
Dimi Lee
Matt Woodrow
Makoto Kato
Andrew McCreight
R. Martinho Fernandes
Hiroyuki Ikezoe
Jon Bauman
Steven MacLeod
Anny Gakhokidze
Johann Hofmann
Kartikaya Gupta