In most cases, `InputEvent.getTargetRange()` of `beforeinput` event should
return `Selection` ranges at dispatching the event.
This patch also handles special cases.
* composition change - target range should be the previous composition string
which will be replaced with new composition string.
* replace text - target range should be the replace range. This is used by
spellchecker.
* drop - target range should be the drop point.
However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:
* surrogate pair boundary
* grapheme cluster boundary like complex emoji
* word/line deletion deletion
* `Backspace` or `Delete` from collapsed selection
* to end of unnecessary whitespaces
For supporting these cases, we need to separate
`HTMLEditor::HandleDeleteSelection()` and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and `InputEvent.getTargetRanges()` may be important for
feature detection of `beforeinput` event so that we should put off the big
changes to bug 1618457.
Differential Revision: https://phabricator.services.mozilla.com/D64730
--HG--
extra : moz-landing-system : lando
`InputEventOptions` should be able to take target ranges for `beforeinput`
event. However, it requires to include `StaticRange.h` from `nsContentUtils.h`
even though most `nsContentUtils.h` users don't need it. Therefore, this patch
moves it from `nsContentUtils.h` to new header file.
And makes `nsContentUtils::DispatchInputEvent()` moves the target ranges
from `InputEventOptions` to `InternalEditorInputEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D64729
--HG--
extra : moz-landing-system : lando
`InputEvent.getTargetRanges()` can be used only when event type is
`beforeinput`. So, it may be used for feature detection of `beforeinput`
event because Chrome does not implement `onbeforeinput` event handler attribute.
Therefore, this patch makes it behind the pref for `beforeinput` event.
Differential Revision: https://phabricator.services.mozilla.com/D64728
--HG--
extra : moz-landing-system : lando
Note that the input can be `EditorDOMPointInText`, but modified range may start
and/or end with different container. Therefore, it needs to take
`EditorDOMPoint` rather than `EditorDOMPointInText`.
Differential Revision: https://phabricator.services.mozilla.com/D64339
--HG--
extra : moz-landing-system : lando
Fallback to using shmem to pass video frame if allocating GPU-backed memory fails.
Differential Revision: https://phabricator.services.mozilla.com/D64266
--HG--
extra : moz-landing-system : lando
On some RDL situations we may create the new item, then destroy the old one
afterwards.
When this is the order of operations, the image would end up unregistered, and
thus not invalidating the canvas frame.
Differential Revision: https://phabricator.services.mozilla.com/D64995
--HG--
extra : moz-landing-system : lando
AnimationInfo has a bunch of member variables that are not necessary for APZ.
Differential Revision: https://phabricator.services.mozilla.com/D64855
--HG--
extra : moz-landing-system : lando
Calling CreateOrRecyleWebRenderUserData is a bit expensive in the case where
there is no animation. The case is pretty common.
Note that even if there is a WebRenderAnimationData having an AnimationInfo,
on the nsIFrame, it's going to be discarded since the WebRenderAnimationData
is not marked as being used.
Differential Revision: https://phabricator.services.mozilla.com/D64853
--HG--
extra : moz-landing-system : lando
Idle runnables do weird things involving unlocking the event queue mutex while
looking for runnables, such that queueing one from off the main thread might
cause it to basically never run if it gets queued during one of those
temporary-unlock periods.
Differential Revision: https://phabricator.services.mozilla.com/D65019
--HG--
extra : moz-landing-system : lando
It's a testcase for Office Online Server duplicated from `test_bug1514940.html`.
The original test listens to `CheckKeyPressEventModel` event which is fired
when the `keypress` event model is changed from the default mode. Therefore,
this test also needs to listen to the event for avoiding intermittent failure
which is caused by running the tests before the mode change.
However, unfortunately, for keeping the performance of web apps which don't
need our mode changes, we can check the event only on debug build. Therefore,
this patch makes the test run only on debug build.
Finally, this patch renames `test_bug154940.html` too because it tests
special behavior on specific web app and the new test name explains it like
the test for Office Online Server.
Differential Revision: https://phabricator.services.mozilla.com/D64919
--HG--
rename : dom/events/test/test_bug1514940.html => dom/events/test/test_use_split_keypress_event_model_on_old_Confluence.html
extra : moz-landing-system : lando
With adding new type, `EditorDOMPointInText` whose container is
`RefPtr<dom::Text>`, we can replace `WSRunScanner::WSPoint` and make
`WSRunScanner` and `WSRunObject` can use its various API. Then, this
patch adds a lot of `NS_ASSERTION`s which can detect existing bugs.
Note that it may look like redundant that `EditorDOMPointInText::IsChar*()`
requires `EditorDOMPointInText::IsEndOfContainer()` check before that.
However, this makes what the callers check clearer.
Differential Revision: https://phabricator.services.mozilla.com/D64336
--HG--
extra : moz-landing-system : lando
We copy IAT for ntdll.dll into a new process so that our hook code can use
ntdll's functions even in the early stage. However, IAT can be modified and
some entries may point to an address which is not valid in the child process.
In such a case, we should not copy IAT. One example is Windows compat mode
which redirects some ntdll functions into AcLayers.dll via IAT.
With this patch, we verify each IAT entry and if any of them is outside ntdll,
we give up using the launcher process and start the browser process.
Differential Revision: https://phabricator.services.mozilla.com/D62852
--HG--
extra : moz-landing-system : lando
This patch converts the BMP decoder to use SurfacePipe instead of using
AllocateFrame and Downscaler directly. As a result, it now uses the
accelerated premultiplication path, honours the
SurfaceFlags::NO_PREMULTIPLY_ALPHA flag, and allows for a path forward
to support color management and clipboard better.
Differential Revision: https://phabricator.services.mozilla.com/D64866
--HG--
extra : moz-landing-system : lando
Maybe we should be using some native color, but the background for that is white
in my testing, so probably not, or at least probably it can be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D64816
--HG--
extra : moz-landing-system : lando
The SpiderMonkey Debugger API maintains a flag per-debuggee that tracks whether
the SpiderMonkey should notify the debugger when new frames are entered, and
whether the JIT scripts associated with the debuggee realm have been compiled
with debug instrumentation. To avoid constantly needing to clear and regenerate
JIT scripts, the flag is permanently enabled once "onEnterFrame" has been used
with a given Debugger instance, and when the flag is enabled, there is a
runtime performance cost.
This runtime cost is what is causing the performance regression here, so to
ensure that the flag is cleared at the end of a given instant-eval, we only
set "onEnterFrame" on a new temporary Debugger instance, instead of setting
it on th existing persistent Debugger instance.
Differential Revision: https://phabricator.services.mozilla.com/D64912
--HG--
extra : moz-landing-system : lando
This is similar to the fix in bug 1614079 where we need to account
for a descendant that might match past a process boundary.
Differential Revision: https://phabricator.services.mozilla.com/D63974
--HG--
extra : moz-landing-system : lando
This patch improves the performance of compositor surfaces in
two ways:
(1) Ignore primitives behind the first compositor surface when
determining whether a tile needs to be moved to the overlay
(alpha) pass. This means WR only moves a tile to the alpha
pass when it has primitives that overlap with the compositor
surface bounding rect, and are ordered after that compositor
surface. In practice, this means most tiles are able to
remain in the fast (opaque) path. Typically, a small number
of tiles that contain overlay video controls are moved to the
alpha pass.
(2) Register the opaque compositor surfaces as potential occluders.
This allows tiles that are completely covered by a compositor
surface to be removed from the compositor visual tree, which
helps both the simple and native compositor modes.
Between them, these optimizations typically mean that when watching
video in full-screen, nothing is composited except the video surface
itself, and some small region(s) where video overlay controls are
currently active.
Differential Revision: https://phabricator.services.mozilla.com/D64909
--HG--
extra : moz-landing-system : lando
- Generalize enumeration over unique sheets to take any array of sheets.
- Add check if the new adoptedStyleSheets only appends sheets.
- Handle append case for new adoptedStyleSheets.
- Add WPT test case for duplicate sheets in the ShadowRoot.
- Add WPT test cases for appending sheets.
Differential Revision: https://phabricator.services.mozilla.com/D64686
--HG--
extra : moz-landing-system : lando
