The two loops where they're used can't walk across shadow boundaries, so we only
need to check for NAC.
We don't have forms in NAC, so avoid silly book-keeping and just return early
for those cases.
Differential Revision: https://phabricator.services.mozilla.com/D53045
--HG--
extra : moz-landing-system : lando
It is no longer needed with captured tracks' lifetimes spanning across seek
operations.
Differential Revision: https://phabricator.services.mozilla.com/D52051
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
It is no longer needed with captured tracks' lifetimes spanning across seek
operations.
Differential Revision: https://phabricator.services.mozilla.com/D52051
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
This is especially important for media elements playing MediaStreams, since the
streams can be manipulated to end playback of the elements synchronously by
either stopping or removing their tracks.
Differential Revision: https://phabricator.services.mozilla.com/D49385
--HG--
extra : moz-landing-system : lando
The remaining notification methods are moved in a separate commit. The
files are renamed to `MutationObservers.*` in a follow-up commit.
Depends on D51824
Differential Revision: https://phabricator.services.mozilla.com/D51825
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
It started progressing as soon as we set up the rendering of the tracks in the
stream, which is too early according to the HTMLMediaElement spec.
Now it starts progressing when we're potentially playing. The difference being
that we now wait for mReadyState to go beyond HAVE_CURRENT_DATA before hooking
up the time progression mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D49354
--HG--
extra : moz-landing-system : lando
This makes all inputs to IsPotentiallyPlayin() Watchable when we're playing a
MediaStream.
Differential Revision: https://phabricator.services.mozilla.com/D49353
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
For allowing `TextEditor` to dispatch DOM events synchronously, we should
remove `AutoScriptBlocker` in `TextControlState::SetValue()` right now.
According to the comment around the `AutoScriptBlocker`, `PrepareEditor()`
may be called while setting value. Therefore, this patch makes
`AutoTextControlHandlingState` call it if `PrepareEditor()` is called
while handling `SetValue()` and when the top most `SetValue()` ends its job.
Depends on D51396
Differential Revision: https://phabricator.services.mozilla.com/D51397
--HG--
extra : moz-landing-system : lando
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
`TextControlState::SetValue()` does 4 things.
1. Committing composition if there is and if possible.
2. Setting value with `TextEditor` if text editor and frame are available.
3. Setting value without `TextEditor` otherwise.
4. Notifying value changed.
We can split #2 and #3 from it now because `AutoTextControlHandlingState`
manages nested actions. Therefore, this patch creates
`SetValueWithTextEditor()` and `SetValueWithoutTextEditor()` which take
`AutoTextControlHandlingState`.
Depends on D51394
Differential Revision: https://phabricator.services.mozilla.com/D51395
--HG--
extra : moz-landing-system : lando
Currently, only `HTMLInputElement` reuses `TextControlState` instance since
`HTMLTextAreaElement` had the instance as a member rather than allocate it.
Now, all instances are allocated in the heap independently for guaranteeing
their lifetime. So, the reuse mechanism should be managed by
`TextControlState` itself.
Depends on D51393
Differential Revision: https://phabricator.services.mozilla.com/D51394
--HG--
extra : moz-landing-system : lando
Currently, nobody guarantees that `TextControlState` won't be deleted while
it handles something with `MOZ_CAN_RUN_SCRIPT` methods.
This patch hides its destructor (and constructor) for making only
`TextControlState` itself can delete its instances. Then, if instance owner
wants to delete it while handling action(s), the oldest `AutoHandlingState`
will delete the `TextControlState`.
Depends on D51392
Differential Revision: https://phabricator.services.mozilla.com/D51393
--HG--
extra : moz-landing-system : lando
Some members of `TextControlState` are initialized and restored in same block
scopes. Therefore, with creating new stack only class and storing latest one
with a new member variable, we can store all of them in the stack.
Depends on D51391
Differential Revision: https://phabricator.services.mozilla.com/D51392
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
When JS is paused, VRService will automatically shutdown because the timer is not updated,
we used to create a new VRDisplay to JS. However, the page is still using the older VRDisplay,
so it can't get the newest VRDisplayInfo status. We should exit presentation and
apply the VRDisplayInfo status to the original VRDisplay instead of creating new one.
Besides, we also need to release the VR screen buffer after exiting the immersive mode to avoid eglMakeCurrent error.
Differential Revision: https://phabricator.services.mozilla.com/D50558
--HG--
extra : moz-landing-system : lando
The spec change HTMLObjectElement tabIndex default to 0, but `test_object_plugin_nav.html` will fail due to HTMLObjectElement’s sequence focus and .focus() rely on default tabIndex. In this patch I separate the logic to not rely on default tabIndex for HTMLObjectElement's plugin type and align the spec.
Differential Revision: https://phabricator.services.mozilla.com/D50801
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Andreas Pehrson
Csoregi Natalia
Narcis Beleuzu
John Dai
Dorel Luca
Bogdan Tara
Valentin Gosu
Matt Woodrow
Brian Grinstead
Coroiu Cristina
Mirko Brodesser
Alex Catarineu
Mihai Alexandru Michis
Masayuki Nakano
Noemi Erli
Edgar Chen
Edwin Takahashi
Daosheng Mu