Rework the MediaKeys class to shutdown when its parent inner window is destroyed
rather than the document it's created in. This is done to mitigate the case
where a MediaKeys is created in an about:blank document that has not yet
undergone its async load (i.e. blank document that will stay blank, blank
documents loading to other pages will still clobber their keys on load). This
specifically addresses cases where sites could create an iframe, not wait for
load, create a MediaKeys in the iframe, and then find the keys had become
unusable.
This is achieved by associating MediaKeys instances with their inner window and
having the window notify keys when a window is going to be destroyed. I decided
to use this approach rather than have MediaKeys observe for window destruction
for a few reasons:
- The keys would need to support weak references to use the observer service in
the desired way. Implementing this interface on the MediaKeys adds a
non-trivial level of complexity and means the keys would implement the WeakPtr
interface (already in place prior to this patch) and also the NS weak
reference interface, which I found confusing.
- If the inner window stores pointers to MediaKeys created in it, it can be self
aware of if EME activity is taking place within it. The allows us to better
identify EME activity in documents. Historically one of the ways we'd
determined EME activity by checking if media elements have MediaKeys attached,
but this had lead to issues where if MediaKeys are created but not attached
to a media element we overlook them. With this patch's changes, we can also
have a document check its inner window to see if there are any MediaKeys. This
patch uses this to extend our check to avoid bfcaching pages with EME content.
- There appears to be prior art using a similar approach for audio contexts and
peer connections, which I assume is sensible and I'm not reinventing the wheel
by following.
Differential Revision: https://phabricator.services.mozilla.com/D98641
If MediaKeys::Init is called before an about:blank doc has performed its async
load, then that document will not have a channel and thus will not have a load
info. This means we cannot look up the top level principal on such a document.
Since we need the top level principal to ensure GMPs are appropriately isolated
from one another, this patch checks the document above the current doc for a
channel and load info in the case the current document does not have one. Since
an about:blank document is considered in the same origin as its parent, this
should be suitable. This process is done recursively to handle edge cases.
Differential Revision: https://phabricator.services.mozilla.com/D97322
Provide coverage that ensures we can:
- Call navigator.requestMediaKeySystemAccess() and receive access
- Call createMediaKeys on the access object
in iframes that are same and different origin.
This should work when waiting for an iframe to fire the load event, but I also
provide a case for if we do not wait for load. It's undesirable to not wait for
the load, but we've historically worked in this case (if this was intentional is
not clear to me). So providing such a test allows for coverage of this case as
long as we want to continue supporting it. Said test will be red as of this
patch, but an immediate follow up will restore our compat with this case.
Differential Revision: https://phabricator.services.mozilla.com/D97321
Instead of having a separate timer for each quota client, we can use a single
timer in the QuotaManager for handling timeouts of all quota clients. The
original shutdown timeout of the quota manager itself can now be removed,
as AbortOperations is already called through InitiateShutdownWorkThreads on
each quota client.
This also moves MaybeRecordShutdownStep to the QuotaManager, which allows
easier access through the singleton instance returned by QuotaManager::GetRef.
Differential Revision: https://phabricator.services.mozilla.com/D98073
This patch changes the way how we abort operations when clearing of data is
requested. Instead of aborting all operations for given origin, we now abort
all operations for given directory locks which are blocking clearing of data.
Differential Revision: https://phabricator.services.mozilla.com/D98609
This is another regression by bug 1658948 and Windows only.
When user script calls element.focus() during keyboard event, our TSF client
implementation commits composition string.
It is unnecessary to call SetInputContext when real keybaord event is fired.
Because,
- If keybaord event is fired, virtual keybaord is already shown
- We don't open virtual keyboard when physical keyboard is available on Android
So I shouldn't call SetInputContext on user interaction by keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D98882
There are two new lints introduced since IOUtils was written that we're hitting
now:
* IOUtils::InternalFileInfo's constructor does not initialize `mType`, `mSize`,
`mLastModified`, and `mPermissions`; and
* We should be using a nested namespace statement.
We haven't hit them since these lines haven't been touched, but I noticed them
on the code review frontend.
Differential Revision: https://phabricator.services.mozilla.com/D99163
Previous behavior was to allow requests if the user has ever interacted with
the window. This patch changes from sticky activation to transient
activation.
WindowContext is used rather than Document for the
HasValidTransientUserGestureActivation() test because user activation is a
property of the Window/global.
The error reported when WindowContext is null is the same as that for missing
transient activation, which is keeping the existing behavior.
https://searchfox.org/mozilla-central/rev/66547980e8e8ca583473c74f207cae5bac1ed541/dom/base/Document.cpp#15806
i.e. a missing WindowContext is still treated as missing transient activation.
Depends on D98274
Differential Revision: https://phabricator.services.mozilla.com/D98275
There are two new lints introduced since IOUtils was written that we're hitting
now:
* IOUtils::InternalFileInfo's constructor does not initialize `mType`, `mSize`,
`mLastModified`, and `mPermissions`; and
* We should be using a nested namespace statement.
We haven't hit them since these lines haven't been touched, but I noticed them
on the code review frontend.
Differential Revision: https://phabricator.services.mozilla.com/D99163
The DOM presentation tests require an implementation of
nsISocketTransport that doesn't actually implement anything,
for some reason.
Re-implementing that in C++ allows me to make nsISocketTransport
builtinclass.
Differential Revision: https://phabricator.services.mozilla.com/D98861
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 DOM presentation tests require an implementation of
nsISocketTransport that doesn't actually implement anything,
for some reason.
Re-implementing that in C++ allows me to make nsISocketTransport
builtinclass.
Differential Revision: https://phabricator.services.mozilla.com/D98861
Starting with one of my earlier patches in Bug 1657404, FreeBSD started seeing
an error,
```
ld.lld: error: undefined hidden symbol:
mozilla::dom::SetGamepadLightIndicatorColor
```
We don't build this codepath as part of our regular Firefox testing, and so I
didn't see the issue.
Luckily, Jan Beich <jbeich@FreeBSD.org> noticed the issue and offered up this
patch. They unfortunately can't be given credit because they are protesting
our requirement for 2FA in Phabricator.
Differential Revision: https://phabricator.services.mozilla.com/D98973
- Remove MOZ_WAYLAND_CFLAGS and /ipc/chromium/chromium-config.mozbuild from ffmpeg58/moz.build
- Build ffvpx with vaapi support at ffvpx/moz.build
- Move gfx related headers from DMABUFSurfaceImage.h to DMABUFSurfaceImage.cpp and implement
the gfx methods there.
- Remove GL headers from DMABufSurface.h and forward declare GLuint/GLContext there.
- Move mutex/MessageLoop/task related headers from nsWaylandDisplay.h to nsWaylandDisplay.cpp.
- Move mozva.cpp to mozva.c due to linking issues
Depends on D90556
Differential Revision: https://phabricator.services.mozilla.com/D90557
Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.
Depends on D90554
Differential Revision: https://phabricator.services.mozilla.com/D90555
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Differential Revision: https://phabricator.services.mozilla.com/D98775
This is intended to be a hotfix for the URL bar regression. Ideally there should be a spec or this behavior should be removed completely.
Previously select() scrolled back to the start position before the regression, but this fix does not restore that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D98972
The RDD process startup being asynchronous make the operation trivial. Unlike with the GPU process, we can immediately tell the MediaFormatDecoder that a new decoder is needed when the RDD died.
Recovery will immediately occur with little visible interruption.
Differential Revision: https://phabricator.services.mozilla.com/D98571
different init segment may yield the same AudioInfo object; so we can't rely on the AudioInfo value to determine if we should use the new init segment or not.
Depends on D98874
Differential Revision: https://phabricator.services.mozilla.com/D98875
different init segment may yield the same AudioInfo object; so we can't rely on the AudioInfo value to determine if we should use the new init segment or not.
Depends on D98874
Differential Revision: https://phabricator.services.mozilla.com/D98875
Add the permission to the geckoview manifest, as previously attempted. Also disable failing tests
to enable a green test run. Add permission to adb.py grants list for good measure.
Differential Revision: https://phabricator.services.mozilla.com/D98809
mLastOverFrame is a WeakFrame, it could possibly be nulled-out, for example
after restyling, and the sub-document won't be able to be notified the mouse
leaving.
Differential Revision: https://phabricator.services.mozilla.com/D98787
When show virtual keyboard, we calls ZoomToFocusedInput to scroll to focused
element. But this method only consider single line control. It means that this
doesn't scroll better position when focused element is multiple such as
content editable. Because we use element rectangle foo zoom to rect.
So I would like to change this for <textarea> and contenteditable.
If <textarea> or contenteditable, we should use caret frame to scroll to
better position.
Differential Revision: https://phabricator.services.mozilla.com/D96374
Just remove a bunch of indentation and use 2-spaces like the usual Gecko / JS
style.
Remove unneeded setBoolPref (pushPrefEnv takes care of that).
Differential Revision: https://phabricator.services.mozilla.com/D98676
- Remove MOZ_WAYLAND_CFLAGS and /ipc/chromium/chromium-config.mozbuild from ffmpeg58/moz.build
- Build ffvpx with vaapi support at ffvpx/moz.build
- Move gfx related headers from DMABUFSurfaceImage.h to DMABUFSurfaceImage.cpp and implement
the gfx methods there.
- Remove GL headers from DMABufSurface.h and forward declare GLuint/GLContext there.
- Move mutex/MessageLoop/task related headers from nsWaylandDisplay.h to nsWaylandDisplay.cpp.
Depends on D90556
Differential Revision: https://phabricator.services.mozilla.com/D90557
Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.
Depends on D90554
Differential Revision: https://phabricator.services.mozilla.com/D90555
Most of time, mp3 file should only have one or none ID3v2 header, but sometime we can see a file incorrectly containing multiple ID3v2 headers where the second one is following by the first one.
Therefore, in this situation, we should keep parsing following ID3v2 header, even if we've parsed one, and report multiple headers size together in order to skip correct offset for finding the correct first frame.
Differential Revision: https://phabricator.services.mozilla.com/D98651
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
This is a best-effort thing of course, but so is the rest of the
visibility threshold stuff in practice and this should be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D98360
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
### Story
While the exisiting top browsing context is replaced, SessionStorage relies on
itself been propagated by SessionStore. However, this has been disabled in
SessionHistory in the parent process.
Therefore, we need to propagate SessionStorage data by propagating
BackgroundSessionStorageManager.
### Notes
This patch assumes that the target top-level browsing context shouldn't have
been registered to BackgroundSessionStorageManager. If this can happen, we will
either need to merge SessionStorage data into it or find a proper (earlier)
place to update sManagers.
### Test Plan
Test: D97763
Try: https://treeherder.mozilla.org/jobs?repo=try&revision=2acc7b393fb80b640f4fbe3ade1da7dd440c380e&selectedTaskRun=KK6XhR-sQuqv5lcntVLc2w.0
Differential Revision: https://phabricator.services.mozilla.com/D98082
The cleanup mostly includes:
- changing the suffix of iteration methods from "If" to "Matching"
- changing the argument type of Condition from a raw pointer to a reference
- changing output parameters to return values
- changing iter-based for loops to range-based for loops
- renaming ForceKillDatabases to ForceKillAllDatabases
Differential Revision: https://phabricator.services.mozilla.com/D98346
Passing in a callable and its arguments to RunOnBackgroundThread was fine
before we started passing in already_AddRefed<nsIFile>. However, if we fail to
get an event target, then we drop all our arguments and in debug builds
already_AddRefed<T> asserts that it was moved out of.
Now we require callers of RunOnBackgroundThread to pass in a closure that
contains all the bindings they require, which has the added bonus of making
lifetimes more explicit. As part of this refactor, all the `ReadSync` etc
methods now take raw nsIFile* pointers since they are called in a scope that
has them refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D98273
When re-creating element prototypes for elements within localized elements we
must set the mIsAtom correctly on the prototype.
Differential Revision: https://phabricator.services.mozilla.com/D97799
No need to special case here as both already use cached selection. This makes it consistent with SetSelectionStart etc.
Differential Revision: https://phabricator.services.mozilla.com/D98185
Classes that inherit from DiscardableRunnable are only promising that it is OK
for Run() to be skipped, rather than promising that Cancel() is effective.
Differential Revision: https://phabricator.services.mozilla.com/D98117
Client::AbortOperations no longer supports the case when an empty origin string
is passed (which was used to abort all operations).
Differential Revision: https://phabricator.services.mozilla.com/D98344
Currently, the gamepad code uses a uint32_t as a handle and does some trickery
with it by trying to create a unique ID and adding an offset to it for VR code.
This can (and has) led to errors where the developer forgets to perform the
arithmetic and sends the wrong number to the wrong manager.
This change created a strongly-typed handle that remembers which service it
belongs to. This should eliminate such accidents.
Differential Revision: https://phabricator.services.mozilla.com/D96273
A substantial refactor of GamepadPlatformService:
1. Easier to understand lifetime
2. Correct usage of mutexes to protect shared state
3. Clear separation of "service owner" and "service user"
4. Simplify logic in some places
5. Better variable names
Differential Revision: https://phabricator.services.mozilla.com/D96664
Currently, the list of monitoring observers is stored in the
GamepadPlatformService. But it's possible for testing to start before an
event channel has been created, or to exist longer. That could result in the
GamepadPlatformManager being created-destroyed multiple times along with
this list.
Probably the simplest thing to do here is just have the list be its own
indepedent entity
Differential Revision: https://phabricator.services.mozilla.com/D96663
No need to special case here as both already use cached selection. This makes it consistent with SetSelectionStart etc.
Differential Revision: https://phabricator.services.mozilla.com/D98185
This simplify the code a bit and also fix FocusIsOutOfProcess isn't set correctly
for a certain case, e.g. framer calls iframe.focus() on a OOP iframe.
Differential Revision: https://phabricator.services.mozilla.com/D96720
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
This is useful for printing. Naming is confusing IMO, but my read of the
docs and experimentation agree this is what we want :)
Differential Revision: https://phabricator.services.mozilla.com/D98415
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
Chris Peterson
Bryce Seager van Dyk
Jan Varga
Mihai Alexandru Michis
Andreas Farre
Butkovits Atila
Emilio Cobos Álvarez
Mark Banner
Joel Maher
Simon Giesecke
Csoregi Natalia
Makoto Kato
Barret Rennie
Karl Tomlinson
Razvan Maries
Andrew McCreight
Sean Feng
Kagami Sascha Rosylight
Chris Martin
Martin Stransky
Henri Sivonen
Andreas Pehrson
Jean-Yves Avenard
Nico Grunbaum
Bogdan Tara
Dan Minor
Cosmin Sabou
Jeff Gilbert
Christoph Kerschbaumer
R. Martinho Fernandes
Geoff Brown
Edgar Chen
Sylvestre Ledru
Andrew Sutherland
Dale Harvey
Steve Fink
yulia
alwu
Matt Woodrow
Hiroyuki Ikezoe
Kershaw Chang
Tom Tung
Tom Tung
Jan de Mooij
Dave Townsend
Akihiko Odaki
Byron Campen [:bwc]
Masayuki Nakano
Robert Mader
Alexis Beingessner