And kick a reflow for the sticky elements when the dynamic toolbar is hidden so that
the sticky elements' position laid out on the main-thread is properly updated there.
These stuffs are basically same as we've done for position:fixed elements.
Differential Revision: https://phabricator.services.mozilla.com/D223906
This comment doesn't make sense any more:
* Scrollers don't use native anything.
* Extensions can't openDialog themselves anymore.
This would allow user CSS to e.g. make PiP windows transparent. An
alternative would be to use scrolling="false" on the PiP window, but
since the restriction doesn't really seem necessary seems worth
removing.
Differential Revision: https://phabricator.services.mozilla.com/D175952
This comment doesn't make sense any more:
* Scrollers don't use native anything.
* Extensions can't openDialog themselves anymore.
This would allow user CSS to e.g. make PiP windows transparent. An
alternative would be to use scrolling="false" on the PiP window, but
since the restriction doesn't really seem necessary seems worth
removing.
Differential Revision: https://phabricator.services.mozilla.com/D175952
This is all super-hacky (see a lot of the XXXcjones comments).
Simplify it... We never create widgets with a bare native parent but no
nsIWidget parent. Pass nsIWidgets and deal with things correctly.
There were also things that were dealing with stuff that can't happen,
like top level popups, children of PuppetWidgets, or such.
Instead of overriding Create(), let's just teach nsBaseWidget about
non-native (headless/puppet) widgets.
Remove lots of old APIs for the native window stuff that are unused
and/or unimplemented.
Differential Revision: https://phabricator.services.mozilla.com/D224613
Pretty sure that we can't hit that case right now, and try with MOZ_ASSERT
agrees with me at least.
Popups don't get there. For puppet widgets, mParentWidget is provided
explicitly.
This code is all super messy and can be cleaned-up significantly.
See following patch.
Differential Revision: https://phabricator.services.mozilla.com/D224612
According to test result on tryserver, the constructor may receive text frame,
although I couldn't reproduce it with writing tests. Then, it'll return
the text node as the mouse event target after dispatching a pointer event.
However, mouse events need to be targeted to element node. Therefore, it's
wrong to use the frame when `aTargetContent` is specified.
Additionally, for the last resort, it should refer an inclusive ancestor element
of the target frame content if `aTargetContent` is not specified and the event
should be targeted to an element.
Finally, there is another path to set non-element node in
`PresShell::EventHandler::DispatchEventToDOM`. The path is not the cause of
the reported case, but we should fix it too.
Differential Revision: https://phabricator.services.mozilla.com/D222091
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
When `HTMLEditor` handles the design mode, `IMEContentObserver` observes the
`<body>` if there is. However, web apps may remove it. Then, we need to
recreate `IMEContentObserver` with emulating a focus move because it's difficult
to compute the difference between the old root and the new root (IME focus
notification sends all content to the parent, it's faster in most cases in this
situation). This was fixed in bug 1911010. However, there are remaining issues
after that.
When new `<body>` or the original `<body>` is connected again,
`IMEContentObserver` does not restart to observe the new `<body>`. So,
`IMEContentObserver` working differently after the `<body>` is even temporarily
removed. This make it harder to reproduce reported bugs.
Additionally, if the document element is removed, `IMEContentObserver` won't
be recreated until the document gets focus again even after new root and/or
`<body>` element is connected. This makes IME users inconvenient with such
tricky editors.
This patch makes `HTMLEditor::NotifyRootChanged` notifies `IMEStateManager`
of the editor root element change. Then, the new method of `IMEStateManager`
updates IME enabled state and recreate `IMEContentObserver` with emulating
a focus move.
Differential Revision: https://phabricator.services.mozilla.com/D220362
This patches allows
1. when the selection is shadow-crossing, dragging it will have the
correct the drag image correctly displayed. It's hard to test, so
no tests for this.
2. The selection can now be serialized and dropped.
`test_drag_drop_shadow_crossing_selection.html` is the test for
this.
Differential Revision: https://phabricator.services.mozilla.com/D217318
This patches allows
1. when the selection is shadow-crossing, dragging it will have the
correct the drag image correctly displayed. It's hard to test, so
no tests for this.
2. The selection can now be serialized and dropped.
`test_drag_drop_shadow_crossing_selection.html` is the test for
this.
Differential Revision: https://phabricator.services.mozilla.com/D217318
This patches allows
1. when the selection is shadow-crossing, dragging it will have the
correct the drag image correctly displayed. It's hard to test, so
no tests for this.
2. The selection can now be serialized and dropped.
`test_drag_drop_shadow_crossing_selection.html` is the test for
this.
Differential Revision: https://phabricator.services.mozilla.com/D217318
This patches allows
1. when the selection is shadow-crossing, dragging it will have the
correct the drag image correctly displayed. It's hard to test, so
no tests for this.
2. The selection can now be serialized and dropped.
`test_drag_drop_shadow_crossing_selection.html` is the test for
this.
Differential Revision: https://phabricator.services.mozilla.com/D217318
When an element starts capturing a pointer, pointer/mouse boundary events are
dispatched by `EventStateManager::PreHandleEvent` [1]. However, when the
capturing element loses the capture, they are not dispatched.
When the pointer capture is implicitly released, the pointer may be over another
document. Therefore, this patch synthesizes an internal `ePointerMove` and
`eMouseMove` on the widget to make `PresShell::HandleEvent` redirects the event
to proper document under the pointer.
Unfortunately, I add 2 manual tests into WPT. The reason is, a drag operation
across document boundary with test driver does not work even if I specify the
pointer position within the parent document coordinates. This is same both on
Firefox and Chrome. Additionally, writing the new tests as a mochitest won't
work too. If I use synthesized mouse events, I see similar failure.
Additionally, when I use native events, it works, but unstable to run on CI.
1. https://searchfox.org/mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02/dom/events/EventStateManager.cpp#1139-1140
Differential Revision: https://phabricator.services.mozilla.com/D218896
Determining if a node is selected is a super-hot code path,
which at times introduces jank both in Reflow and Painting.
This is due to each node comparing its position to the range's start and end point,
which even happens several times (`nsINode::IsSelected()` and `Selection::LookupSelection()`).
In worst cases, this can lead to reflow which takes several minutes.
This patch introduces a cache which contains all fully selected nodes,
and lives throughout one `PresShell::DoReflow()` call.
Collecting all selected nodes of a selection is very fast.
The selected nodes are then stored in a hash set.
During reflow the check if a node is selected first checks the cache
if the node is fully selected, and otherwise goes through the existing
code to check if the node is partially selected.
Differential Revision: https://phabricator.services.mozilla.com/D217794
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
`PresShell::mCurrentEventTargetContent` may be update to non-element node
when `PresShell::mCurrentEventTargetFrame` is destroyed. Therefore, for
avoiding it, I'd like to add `EventMessage` to the group to consider whether
the content needs to be `Element`. However, adding new members for current
and stack would make `PresShell` members more messy. Therefore, I'd like to
group the data with the simple struct.
Differential Revision: https://phabricator.services.mozilla.com/D217204
Now, we have `nsFocusManager::GetFocusedElementStatic()` which returns focused
element if the `nsFocusManager` instance is available. Therefore, if
`nsFocusManager::GetFocusedElement()` users do not use other methods of
`nsFocusManager`, they can use `nsFocusManager::GetFocusedElementStatic()` and
make themselves simpler.
Note that some callers return early if `nsFocusManager` is not available, but
they do not return error and `nsFocusManager` instance is available in most
time of the life time of the process. Therefore, we can simply stop using the
early return.
Differential Revision: https://phabricator.services.mozilla.com/D217527
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
During a drag session, mouse events are not fired. Therefore, once the drag
session ends, mouse cursor may be anywhere different from the drag start
position. Therefore, `PresShell` should update the last mouse position when it
receives drag events and needs to synthesize a mouse move after the drag session
ends to fire mouse boundary events and updating the hover state.
Differential Revision: https://phabricator.services.mozilla.com/D217080
Before this patch, it could happen that `PresShell::GoToAnchor()` was called while loading a document.
This method did not know about text fragments before,
and would scroll the anchor (ie., the first text directive) to the top of the view.
This was noticeable for pages that took longer to load, where the text directive was scrolled to the center first, and then to the top.
This patch saves the desired vertical scroll position as a member in `PresShell` and makes `GoToAnchor()` scroll to the center as well.
Additionally, this patch updates the test file target document to make it more mobile-friendly.
Differential Revision: https://phabricator.services.mozilla.com/D216039
Since container is transformed, container->GetTransformMatrix will always just put the cross doc parent frame into parent. I checked the history when this code was written, it looks like GetTransformMatrix (via GetResultingTransformMatrix) might have go up more than one parent frame in the case of preserve 3d (combines 3d) frames. That is no longer the case, and GetTransformMatrix is a relatively heavyweight function.
Differential Revision: https://phabricator.services.mozilla.com/D215860
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
