nsPresContext.h is only used for unit conversion, which can be done by Units.h
in a similar fashion.
PresShell.h was needed for some capturing-content stuff which can be moved out
of line.
Differential Revision: https://phabricator.services.mozilla.com/D62170
--HG--
extra : moz-landing-system : lando
And fix a bunch of fallout as we now don't include nsDocShell.h everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D62169
--HG--
extra : moz-landing-system : lando
This change ensures that we always remember to add a text track to media element's track list.
Differential Revision: https://phabricator.services.mozilla.com/D61666
--HG--
extra : moz-landing-system : lando
I thought this would fix <input type=number style="user-select: none">, but
turns out it doesn't.
<input type=number> doesn't have the editor root as a root of the anonymous
subtree, so the current hack wouldn't work, as the anon root wouldn't have the
editable flag. So tweak the code a bit to handle stuff in a simpler way than
setting the flags after the fact, and set the NAC-root flag earlier to avoid
the mOuterWrapper->AppendChildTo(root) call forgetting about root's flags.
I had to tweak one AccessibleCaret test, but that's because it uses <textarea>
with user-select: none, and our behavior there is not particularly sane. It just
happened to work because that test-case also had a bunch of contenteditable
elements, and we stop matching this rule:
https://searchfox.org/mozilla-central/rev/220a3bd6063fcbe5ca50e88dcabdc7dee0aca448/layout/style/contenteditable.css#22
Because the anonymous div now properly matches :-moz-read-write, which made the
rule apply and the test work. See comment 4 of this bug.
I'll fix this stuff up and add some tests for our behavior here in bug 1611699.
I refactored the dragdrop tests to cover more input types, but I ended up not
being able to use them because they're dependent on the content.
Instead I added an extra test and changed the refactor so that it applies to
<input type=search>, as there's layout work going on in bug 558594, and it'd be
unfortunate to regress this there too.
Differential Revision: https://phabricator.services.mozilla.com/D61094
--HG--
extra : moz-landing-system : lando
Please review the changes to Errors.msg very carefully. I caught a number of
mistakes there in self-review (e.g. not renumbering replacement markers
correctly when I added {0} to the beginnings of strings), and my confidence
that I caught them all is only middling.
A few lines (MSG_USELESS_SETTIMEOUT, MSG_TYPEDARRAY_IS_DETACHED,
MSG_NOT_SUBMIT_BUTTON) were removed from Errors.msg either because they were
already unused or because they either were single-user constant strings or
became such in the new setup and we could just use the string version of
ThrowTypeError.
Differential Revision: https://phabricator.services.mozilla.com/D61523
--HG--
extra : moz-landing-system : lando
The code was using activeElement which is not safe inside shadow DOM as it is
retargeted.
Differential Revision: https://phabricator.services.mozilla.com/D61331
--HG--
extra : moz-landing-system : lando
Previously, I added `Selection::mCachedRange` to save allocation cost of
`nsRange`. However, with the previous patch, we don't need the hack anymore
since ranges removed by `Selection::RemoveAllRanges()` are always kept in
the global cache of `nsRange`. Therefore, we can remove the ugly hack right
now.
Differential Revision: https://phabricator.services.mozilla.com/D61239
--HG--
extra : moz-landing-system : lando
The check here was used to prevent calling play or pause during playing or pausing.
However, according to the spec [1], even if media session is playing, we would still want to trigger its play action handler when play action happens. So we should forward all media control key events to the content, not to block any of them.
[1] https://w3c.github.io/mediasession/#handle-media-session-action
Differential Revision: https://phabricator.services.mozilla.com/D60918
--HG--
extra : moz-landing-system : lando
We go to great lengths to try to avoid initializing FrameLoaders during
document updates. That means that when `BindToTree` is called, the element's
FrameLoader is not initialized, and it has no BrowsingContext. Calling
`GetBrowsingContext()` (which happens as a side-effect of
`HTMLIFrameElement::RefreshFeaturePolicy`), however, forces eager
initialization, which can cause any number of problems.
This patch moves that logic from being triggered by `BindToTree` to being
triggered by `BrowsingContext::Embed`, which happens as soon as the
BrowsingContext is bound to the element, but does not force it to be created
early.
Differential Revision: https://phabricator.services.mozilla.com/D55872
--HG--
extra : moz-landing-system : lando
For preparing to remove `nsIPlaintextEditor` interface, this patch moves
all of them to `nsIEditor`, but for avoiding bustage in comm-central, makes
`nsIPlaintextEditor` inherit `nsIEditor` for now (i.e., even with this patch,
script can access old `nsIPlaintextEditor` members with the interface.
In C++ code, this patch moves `SetWrapColumn()`, `InsertTextAsAction()`,
`InsertTextAsSubAction()` and `InsertLineBreakAsSubAction()` because
they do common things between `TextEditor` and `HTMLEditor`. On the other
hand, this does not move `TextEditor::GetTextLength()` because it's designed
only for `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D60820
--HG--
rename : editor/libeditor/tests/test_nsIPlaintextEditor_insertLineBreak.html => editor/libeditor/tests/test_nsIEditor_insertLineBreak.html
extra : moz-landing-system : lando
I made `nsContentUtils::DispatchInputEvent()` update validity of event target
before dispatching `eEditorInput` event in bug 1584963. However, this is not
enough because it updates validity only when the type of `<input>` element is
`mail`, but it's required for other types, for example, `<input required>`.
This patch reverts the hack added in bug 1584963, instead, makes
`TextControlState::SetValueWithoutTextEditor()` notifies `TextControlElement`
of value change before dispatching `eEditorInput` event because it may have made
damage to the performance if `nsContentUtils::DispatchInputEvent()` updated
**all** validity state of the event target.
Differential Revision: https://phabricator.services.mozilla.com/D60828
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Using a weak RNG for the form boundary allows a website operator to perform several
attacks on users (as outlined in https://trac.torproject.org/projects/tor/ticket/22919)
These include:
- Identifying Windows users based on the unseeded RNG
- Identify the number of form submissions that have occurred cross-origin between same-origin submissions
Additionally, a predictable boundary makes it possible to forge a boundary in the middle
of a file upload.
Differential Revision: https://phabricator.services.mozilla.com/D56056
--HG--
extra : moz-landing-system : lando
Changes:
With lack of movement on the bug, mark this test as an expected failure for ubuntu1804 as this bug fails at permafail frequency.
Differential Revision: https://phabricator.services.mozilla.com/D59557
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
`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
`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
