`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
Behind a pref of course. Toggle that pref on on the loading/lazyload test
subdirectory, though there are no tests for the IDL (I guess once the spec PR
lands the existing IDL tests will be updated from the spec).
Differential Revision: https://phabricator.services.mozilla.com/D59764
--HG--
extra : moz-landing-system : lando
When media element is inactive, asking MDSM to seek is actually useless, because all the data we decode won't be showed to user. In addition, we have to store extra pending events for `seeking` and `seeked`, which might result in memory overflow if the inactive page is calling `seek()` all the time.
Therfore, we should delay all seeking tasks while media is inactive, and perform the latest seeking task when media becomes active.
Differential Revision: https://phabricator.services.mozilla.com/D58918
--HG--
extra : moz-landing-system : lando
Two parameters in `SuspendOrResumeElement()` are acutally the same, they are both related with `IsActive()`, so using one parameter is enough.
In addition, we only suspend or resume element by checking element's active state, so rename `mPausedForInactiveDocumentOrChannel` to `mSuspendedForInactiveDocument` which fits the actual situation more.
Differential Revision: https://phabricator.services.mozilla.com/D58749
--HG--
extra : moz-landing-system : lando
In StartDocumentLoad we copy the securityInfo reference from the load channel into a document
member variable. This used to happen only for HTML documents, but other documents (e.g. media)
can be loaded via secure channels, too and thus should have securityInfos. We're using the
securityInfo object to display information in the UI, which would previously fail for images and videos.
Differential Revision: https://phabricator.services.mozilla.com/D59327
--HG--
extra : moz-landing-system : lando
* Revert some partial webgl+oop+vr code.
* More missing FuncScope.
* Fix compile errors.
* Refactor some ifdef'd code to branch and compile on all platforms.
* -Wno-error=unused-result for GCC to allow for (void)MustUse().
Depends on D55739
Differential Revision: https://phabricator.services.mozilla.com/D56169
--HG--
extra : moz-landing-system : lando
* Context loss using RAII
* Move Program reflection Client-side
Depends on D54018
Differential Revision: https://phabricator.services.mozilla.com/D54019
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
Modify IPC method to support notify `ControlledMediaState` to the media controller, and remove the previous implementation.
Differential Revision: https://phabricator.services.mozilla.com/D57572
--HG--
extra : moz-landing-system : lando
We create `MediaControlEventListener` to register itself to the `MediaControlAgent` that is an event source, so that we can receive the media control event from the evnet source and operate media according to different types of event.
`MediaControlEventListener` is also used to notify controlled media state to the media controller. When media first starts playing, or leaves bfcache and has created listener before, we would notify `eStarted`. Notify `eStopped` when media destroys, or enter bfcache and has created listener before. When media's playing state changes, we would notifty `ePlayed` or `ePaused` depeding on media's `mPaused`.
Differential Revision: https://phabricator.services.mozilla.com/D57571
--HG--
extra : moz-landing-system : lando
The test fails with my <input type=number> rewrite because editor fails to
dispatch one input event caused by these mouse events.
The reason for this is that we schedule them from an input event, which fires
from here:
https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/editor/libeditor/EditorBase.cpp#965
Not how at that point we still haven't decremented mPlaceholderBatch. That means
that other stuff that triggers input events from there will not dispatch events.
I think that's a bit unexpected, but it is a preexisting problem, and can't
happen for users because mouse events go through the event loop.
Differential Revision: https://phabricator.services.mozilla.com/D57810
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
This patch is used to change the blessed state for media element under `click-to-play` blocking autoplay policy, which only allows play invocation called from user input handler, eg. `onclick`.
When media aborts current load, we should regard it as a new media. One example is on Youtube they always reuse same media element but replace its url for different video. Therefore, we should reset media's blessed state so that the media with new url can be blocked again.
Differential Revision: https://phabricator.services.mozilla.com/D57192
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Note that `TextControlState::BindToFrame()` may also run script if it's
called without script blocker. However, it shouldn't occur. Therefore,
we don't need to mark it `MOZ_CAN_RUN_SCRIPT`, but we should check
script blocker existence with `MOZ_ASSERT`.
Differential Revision: https://phabricator.services.mozilla.com/D55776
--HG--
extra : moz-landing-system : lando
If `PreareEditor()` returns `NS_OK`, but if the instance is deleted at returning
from it, `GetTextEditor()` will access `mTextEditor`. Therefore, this patch
makes `PrepareEditor()` return error if the instance is destroyed at its end.
Differential Revision: https://phabricator.services.mozilla.com/D55775
--HG--
extra : moz-landing-system : lando
Similar to the previous patch, it may notify selection listeners of native
anonymous tree in `<input>` and `<textarea>` element.
Differential Revision: https://phabricator.services.mozilla.com/D55774
--HG--
extra : moz-landing-system : lando
They are really complicated and can run script while the instance is being
destroyed. Therefore, they should have their own `AutoTextControlHandlingState`
as "kungFuDeathGrip".
Differential Revision: https://phabricator.services.mozilla.com/D55773
--HG--
extra : moz-landing-system : lando
The destructor of `AutoTextControlHandlingState`is marked as
`MOZ_CAN_RUN_SCRIPT`, but it's not checked at build time. And this does not
need to be created when the method does not run script. Therefore, we should
mark its constructor as `MOZ_CAN_RUN_SCRIPT` instead since it's stack only
class so that its constructor and destructor are always called from same
method.
Differential Revision: https://phabricator.services.mozilla.com/D55772
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Fenix wants to ship Web Manifest support, while other Firefox products (e.g., Desktop) don't support it.
With the pref enabled, developers can check, via `link.relList.supports()`, if manifest processing is supported by a particular product.
Differential Revision: https://phabricator.services.mozilla.com/D55064
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
To avoid defining `Loading`, `Loaded`, etc. in the mozilla::dom namespace. Also
it is a bit cleaner and saves some memory in the TextTrack objects by specifying
the size to be smaller.
Differential Revision: https://phabricator.services.mozilla.com/D55312
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
It's a better name, and will avoid confusion when I add other stylesheet caches
outside of the CSS loader.
Depends on D54556
Differential Revision: https://phabricator.services.mozilla.com/D54557
--HG--
rename : layout/style/nsLayoutStylesheetCache.cpp => layout/style/GlobalStyleSheetCache.cpp
rename : layout/style/nsLayoutStylesheetCache.h => layout/style/GlobalStyleSheetCache.h
extra : moz-landing-system : lando
For media element, as the spec requires that we should know the whether it can be allowed to play when we call `media.play()` [1], which means that we should get the result before the play invocation.
Therefore, we request for the play permission when we create media element.
Differential Revision: https://phabricator.services.mozilla.com/D52438
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Previously, we cache only one `TextControlState` instance to reuse. However,
`HTMLTextAreaElement` also started to allocate it in the heap rather than
a part of its instance. Therefore, we should have more room to cache the
instances for saving the allocation cost.
Differential Revision: https://phabricator.services.mozilla.com/D54326
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Previously, we cache only one `TextControlState` instance to reuse. However,
`HTMLTextAreaElement` also started to allocate it in the heap rather than
a part of its instance. Therefore, we should have more room to cache the
instances for saving the allocation cost.
Differential Revision: https://phabricator.services.mozilla.com/D54326
--HG--
extra : moz-landing-system : lando
For media element, as the spec requires that we should know the whether it can be allowed to play when we call `media.play()` [1], which means that we should get the result before the play invocation.
Therefore, we request for the play permission when we create media element.
Differential Revision: https://phabricator.services.mozilla.com/D52438
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
Unlink must not cause an AddRef on the unlinked object, or it is at risk of
leaking. See 1593739 for an example of where this happens.
EndCloningVisually is dangerous in that it tries to do more than just unlink the
video element. It does AddRef in NotifyUAWidgetSetupOrChange, so that must be
avoided.
Previous patches to this bug make sure that MediaDecoder shutdown takes care of
clearing the secondary video container in the MediaDecoder stack, so this is not
actually necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D53832
--HG--
extra : moz-landing-system : lando
This patch does the following:
- Makes cloneElementVisually() return a promise
- Plumbs an event from the MediaDecoderStateMachine's VideoSink to
HTMLVideoElement
- Hooks the event up to resolve the promise from cloneElementVisually()
- Updates tests and their expectations.
Differential Revision: https://phabricator.services.mozilla.com/D53831
--HG--
extra : moz-landing-system : lando
This better follows how MediaDecoder and MediaDecoderStateMachine was
architected.
Differential Revision: https://phabricator.services.mozilla.com/D53710
--HG--
extra : moz-landing-system : lando
Unlink must not cause an AddRef on the unlinked object, or it is at risk of
leaking. See 1593739 for an example of where this happens.
EndCloningVisually is dangerous in that it tries to do more than just unlink the
video element. It does AddRef in NotifyUAWidgetSetupOrChange, so that must be
avoided.
Previous patches to this bug make sure that MediaDecoder shutdown takes care of
clearing the secondary video container in the MediaDecoder stack, so this is not
actually necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D53832
--HG--
extra : moz-landing-system : lando
This patch does the following:
- Makes cloneElementVisually() return a promise
- Plumbs an event from the MediaDecoderStateMachine's VideoSink to
HTMLVideoElement
- Hooks the event up to resolve the promise from cloneElementVisually()
- Updates tests and their expectations.
Differential Revision: https://phabricator.services.mozilla.com/D53831
--HG--
extra : moz-landing-system : lando
This better follows how MediaDecoder and MediaDecoderStateMachine was
architected.
Differential Revision: https://phabricator.services.mozilla.com/D53710
--HG--
extra : moz-landing-system : lando
Unlink of mSrcStream used to rely on EndSrcMediaStreamPlayback to unhook
everything. That method does more than necessary however, and if anything in it
creates a strong reference to the media element, we risk a leak.
This patch takes what's necessary to unhook from EndSrcMediaStreamPlayback and
runs it explicitly from Unlink, to avoid anything unnecessary being run as well.
Differential Revision: https://phabricator.services.mozilla.com/D51906
--HG--
extra : moz-landing-system : lando
Unlink of mSrcStream used to rely on EndSrcMediaStreamPlayback to unhook
everything. That method does more than necessary however, and if anything in it
creates a strong reference to the media element, we risk a leak.
This patch takes what's necessary to unhook from EndSrcMediaStreamPlayback and
runs it explicitly from Unlink, to avoid anything unnecessary being run as well.
Differential Revision: https://phabricator.services.mozilla.com/D51906
--HG--
extra : moz-landing-system : lando
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
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
The following tests are not removed and need to be ported to Shadow DOM:
- test_bug330925.xhtml
- test_bug372086.html
- test_bug319374.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D50650
--HG--
extra : moz-landing-system : lando
Changes:
- remove skiaContent from `dom/html/reftests/autofocus/reftest.list`
Differential Revision: https://phabricator.services.mozilla.com/D50543
--HG--
extra : moz-landing-system : lando
Everytime when we start a controller, we should also update its audible state correctly, in order to request audio focus correctly.
Differential Revision: https://phabricator.services.mozilla.com/D50151
--HG--
extra : moz-landing-system : lando
Bug 917325 started using the `username` token.
Bug 1119063 started using the `new-password` token. This patch also adds support for `current-password` since it's the counterpart to `new-password` and we plan to use it as a signal eventually so want to encourage its use.
Differential Revision: https://phabricator.services.mozilla.com/D50351
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
When `nsTextEditorState::SetValue()` is called with `eSetValue_BySetUserInput`,
we emulate user input. I.e., keep using transaction manager of the editor,
events fired while handling user input should be fired.
Currently, `nsTextEditorState::SetValue()` suppresses multiple state handling
while setting value with calling `mTextListener->SettingValue(true)`. This
is why `"input"` event listeners cannot retrieve the latest state of validation
if `inputType` is `"insertReplacementText"`.
This patch makes it keep managing `mTextListener` when setting the value
programatically. Otherwise, i.e., it emulates user input, editor should
manage it from `EditorBase::NotifyEditorObservers()` instead so that this
patch makes it not managing `mTextListener` in such case.
Differential Revision: https://phabricator.services.mozilla.com/D49571
--HG--
extra : moz-landing-system : lando
It can be unset by NotifyShutdown, to release the VideoFrameContainer in time.
This is unexpected for all paths assuming it will be unset by
EndSrcMediaStreamPlayback().
Depends on D49573
Differential Revision: https://phabricator.services.mozilla.com/D49574
--HG--
extra : moz-landing-system : lando
I don't think these need invalidation of any sort since they only depend on
ancestors, and we recreate accessibles when the element's ancestor chain changes.
Differential Revision: https://phabricator.services.mozilla.com/D49408
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
This flag is only meant for window.open() stuff, so not relevant to iframes at
all.
This preserves the current fission behavior (which is quite broken) of always
showing scrollbars.
The way to control scrollbars for iframes (the scrolling attribute) is not
handled at all for Fission, I filed a bug and left a few FIXMEs.
Differential Revision: https://phabricator.services.mozilla.com/D49292
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
The request is used to track if the promise is resolved or not, so we should call its `Complete()` method once promise is resolved, in order to keep the state of the request correct.
Differential Revision: https://phabricator.services.mozilla.com/D47331
--HG--
extra : moz-landing-system : lando
This is an easier thing to implement interoperably than what we implement now,
which is basically "whatever goes through this function".
Differential Revision: https://phabricator.services.mozilla.com/D47145
--HG--
extra : moz-landing-system : lando
In bug1583978, we are going to remove `AudibleState::eMaybeAudible`. But before that, as `AudibleState::eMaybeAudible` is only used for delaying media playback, so we can remove its usage from media element and move it to the dedicated class to reduce confusion about how and when we should use `AudibleState::eMaybeAudible` or `AudibleState::eNotAudible`.
Differential Revision: https://phabricator.services.mozilla.com/D47153
--HG--
extra : moz-landing-system : lando
Now `AudioChannelWrapper` would only start `AudioChannelAgent` when media starts and stop the agent when media stops. It won't handle any case with `SUSPENDED_BLOCK`.
It's clearer to know when we would start or stop the agent in AudioChannelWrapper.
In addition, in bug1577890, we will remove more unnecessary logic which is used for Fennec only in order to make `AudioChannelWrapper` cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D44747
--HG--
extra : moz-landing-system : lando
Separate the logic of delaying media playback from `HTMLMediaElement`'s `mAudioChannelWrapper` to a new class, because delaying media playback is a special usage of using `AudioChannelAgent`.
It would make the code cleaner and separate the normal usage and the special usage, to reduce confusion.
We usually start `AudioChannelAgent` when media playback starts and stop it when media playback stops, however, in this case, we would start the agent even if media hasn't be started yet, because we would like to use the agent as a connection with `AudioChannelService` in order to receive the resume command when we're able to play delayed playback.
Differential Revision: https://phabricator.services.mozilla.com/D44746
--HG--
extra : moz-landing-system : lando
As we have another usage to know whether media is audible or not, we remove this function from AudioChannelWrapper and make it as media element's function.
In addition, it also makes sense to have this function for media element, because the result is decided by media element's own attributes.
Differential Revision: https://phabricator.services.mozilla.com/D44744
--HG--
extra : moz-landing-system : lando
There are some checking conditions can be reordered or simplified in order to remove some unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D47027
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
We have already had the same checking in `AudioCaptureStreamChange()`, so we can remove the checking in `AudioCaptureStreamChangeIfNeeded()`.
Differential Revision: https://phabricator.services.mozilla.com/D45749
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
We have already had the same checking in `AudioCaptureStreamChange()`, so we can remove the checking in `AudioCaptureStreamChangeIfNeeded()`.
Differential Revision: https://phabricator.services.mozilla.com/D45749
--HG--
extra : moz-landing-system : lando
People keep adding useless null-checks and it was not clear what the consensus
was from bug 1441165, but this should be unobjectionable I guess.
Differential Revision: https://phabricator.services.mozilla.com/D46781
--HG--
extra : moz-landing-system : lando
Tasks dispatched from RunInStableState() can be cancelled if there's a load in
between, so this is not sound.
See nsSyncSection::IsCancelled().
This is the only patch in this bug that is worth uplifting IMO.
Differential Revision: https://phabricator.services.mozilla.com/D46773
--HG--
extra : moz-landing-system : lando
Now, we can get rid of `TextEditRules` and `HTMLEditRules` completely.
And also this patch renames their cpp files to `TextEditSubActionHandler`
and `HTMLEditSubActionHandler`.
`TextEditor::Init()` and `HTMLEditor::Init()` are still complicated due to
`AutoEditInitRulesTrigger`. The following patch will remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45792
--HG--
rename : editor/libeditor/HTMLEditRules.cpp => editor/libeditor/HTMLEditSubActionHandler.cpp
rename : editor/libeditor/TextEditRules.cpp => editor/libeditor/TextEditSubActionHandler.cpp
extra : moz-landing-system : lando
`TextEditRules::DocumentIsEmpty()` is a wrapper of `TextEditor::IsEmpty()` so
that we can get rid of it simply.
`HTMLEditRules::DocumentIsEmpty()` needs to change. It's oddly checks only
`EditorBase::mPaddingBRElementForEmptyEditor` is `nullptr` or not. However,
the editor may be completely empty. And the result may be different from
`TextEditor::IsEmpty()` which is not overridden by `HTMLEditor`. For partially
solving this issue, this patch makes `HTMLEditor` overrides `IsEmpty()` and
optimizes `TextEditor::IsEmpty()`.
With this change, the caller of `HTMLEditRules::DocumentIsEmpty()` may behave
differently in the only caller, `HTMLEditor::SelectEntireDocument()`. And
unfortunately, its root called from `SelectAllCommand::DoCommand()`. However,
it does just collapse `Selection` into the root element (`<body>` or
`Document.documentElement`) if it returns `true`. Therefore, this change
must be safe since anyway `SelectionRefPtr()->SelectAllChildren()` with
the root element is exactly same as `SelectionRefPtr()->Collapse()` with
the empty root element if it's truly empty.
Differential Revision: https://phabricator.services.mozilla.com/D45784
--HG--
extra : moz-landing-system : lando
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
Note that I've confirmed no-cross-origin-autofocus.html works fine with
enabling fission on w3c-test.org.
Differential Revision: https://phabricator.services.mozilla.com/D44950
--HG--
extra : moz-landing-system : lando
We use `NotifyMediaStarted()` and `NotifyMediaStopped()` to notify `MediaControlService` on parent process to start/stop a media controller, and use `NotifyMediaAudibleChanged()` to notify controller's audible state in order to request audio focus.
As our goal is to use media controller to control media element, not for web audio, web speech and other stuffs which also use audio channel agent.
Therefore, we should notify parent process to start/stop controller only for media element, instead of sending a notification in AudioChannelService because that would create media controller for all different consumers which uses audio channel agent.
Differential Revision: https://phabricator.services.mozilla.com/D45591
--HG--
extra : moz-landing-system : lando
Spliting NotifyAudioChannelAgent() to StartAudioChannelAgent() and StopAudioChanelAgent() allows us to start and stop an AudioChannelAgent in a clear naming function, and to do related operation and checking every time we start/stop the agent.
Differential Revision: https://phabricator.services.mozilla.com/D45590
--HG--
extra : moz-landing-system : lando
Note that I've confirmed no-cross-origin-autofocus.html works fine with
enabling fission on w3c-test.org.
Differential Revision: https://phabricator.services.mozilla.com/D44950
--HG--
extra : moz-landing-system : lando
This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
