Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
Previously, scrolling start events always fired on an Accessible for an element, never a text leaf.
However, a text fragment starts in a text leaf node and there may be many other children of the parent element prior to the start of the text fragment.
We want to get a11y clients as close as possible to the fragment, so fire the event on the text leaf node instead.
Unfortunately, we can't fire the Windows event on text leaf nodes, so we have to override this to use the parent in Windows specific code.
Fortunately, we can expose the highlight on Windows via text attributes, so clients can find out exactly what is highlighted, albeit with a bit more work.
This text leaf change is of most benefit on Android, where we can't expose the highlight, but we can move accessibility focus to a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D226587
Previously, scrolling start events always fired on an Accessible for an element, never a text leaf.
However, a text fragment starts in a text leaf node and there may be many other children of the parent element prior to the start of the text fragment.
We want to get a11y clients as close as possible to the fragment, so fire the event on the text leaf node instead.
Unfortunately, we can't fire the Windows event on text leaf nodes, so we have to override this to use the parent in Windows specific code.
Fortunately, we can expose the highlight on Windows via text attributes, so clients can find out exactly what is highlighted, albeit with a bit more work.
This text leaf change is of most benefit on Android, where we can't expose the highlight, but we can move accessibility focus to a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D226587
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
