Also, in EventStateManager, convert `ComputeScrollTarget()` and
`ComputeScrollTargetAndMayAdjustWheelEvent()` to return `ScrollContainerFrame*`
so that we can drop more unnecessarily `do_QueryFrame`.
Due to removing `nsIScrollableFrame` forward declaration in DOM headers, we have
to add `nsIScrollableFrame` forward declaration temporarily in
nsMenuPopupFrame.h to make this patch compile, but we'll remove it once we
remove `nsIScrollableFrame` under layout/.
Differential Revision: https://phabricator.services.mozilla.com/D211496
Also, in EventStateManager, convert `ComputeScrollTarget()` and
`ComputeScrollTargetAndMayAdjustWheelEvent()` to return `ScrollContainerFrame*`
so that we can drop more unnecessarily `do_QueryFrame`.
Due to removing `nsIScrollableFrame` forward declaration in DOM headers, we have
to add `nsIScrollableFrame` forward declaration temporarily in
nsMenuPopupFrame.h to make this patch compile, but we'll remove it once we
remove `nsIScrollableFrame` under layout/.
Differential Revision: https://phabricator.services.mozilla.com/D211496
Only "custom" invoke actions (those with a dash) or well-defined built-in
actions can be defined. Auto action is now implicit from empty/null atom.
Differential Revision: https://phabricator.services.mozilla.com/D206182
Make sure to do no work on insertions if the dir=auto element has
already the right strong directionality, but record that the node might
be the one impacting the dir=auto resolution.
Also get some node flags back.
Differential Revision: https://phabricator.services.mozilla.com/D202071
This will be needed by accessibility for two reasons:
1. Accessibility will need to keep track of explicitly set attr-elements even if they aren't a descendant of any of the refering element's shadow-including ancestors. Accessibility will enforce that restriction itself before using the attr-element.
2. Accessibility will need to be able to distinguish between an attr-associated element obtained from an explicitly set attr-element vs derived using an id string in the content attribute. There are other ways to do this, but they are somewhat ugly.
Differential Revision: https://phabricator.services.mozilla.com/D201660
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
This the "body propagated to root" case to also set aFrame.
This doesn't change behavior for current callers, but would be useful to
simplify the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D200915
This the "body propagated to root" case to also set aFrame.
This doesn't change behavior for current callers, but would be useful to
simplify the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D200915
Having a base class with a single static member doesn't buy us much, and
actually MSVC-compatible compilers don't optimize empty base classes out
(plus the empty base is at the end so it might even take space on Linux
and macOS, untested).
Just put the values in Element.h / Element.cpp which is the common base
class of the relevant elements.
Differential Revision: https://phabricator.services.mozilla.com/D200825
Given some markup like:
```html
<div id=popover popover>
<button id="openDialog">Open Dialog</button>
<dialog id=dialog>
I'm a dialog!
</dialog>
</div>
<button id="openPopover">Open Popover</button>
<button>I do nothing!</button>
```
With some JS like
```js
openDialog.onclick = () => {
dialog.showModal();
}
openPopover.onclick = () => {
popover.showPopover();
}
```
Clicking the "Open Popover" button followed by the "Open Dialog" button results in both the Dialog and Popover being hidden, however the dialog will still be open as modal, rendering the whole page inert, nothing is clickable and there seems to be no way to undo this (unless you use a CloseWatcher gesture such as the Esc key - if you have one available on your device).
It is expected that the popover should not close the dialog, as it causes the invisible Modal Dialog to make the whole page inert, and it is very difficult for users (and developers) to discover how to undo this action (pressing escape).
This was reported in https://github.com/whatwg/html/issues/9998, and WhatWG resolved to fix this, which in https://github.com/whatwg/html/pull/10116.
Differential Revision: https://phabricator.services.mozilla.com/D200686
The test case is a special case that changes focused element from a text control
to an editing host. Therefore, without a focus change, focused editor is
changed from a `TextEditor` to `HTMLEditor`. At this time, `IMEContentObserver`
needs to switch the observing target from the anonymous content if `<input>` to
children of it.
However, the editable content becomes completely changed without a focus change
in the DOM. Therefore, `IMEStateManager` needs to synthesize a fake focus move
for IME. Therefore, this patch make `IMEStateManager` recreate
`IMEContentObserver` if active one is not observing editable content for the
focused element under "current" conditions at checking it. (When
`IMEContentObserver` is being destroyed, it sends "blur" notification to IME
and the new `IMEContentObserver` instance posts "focus" notification with
all editable content data. I.e., recreating `IMEContentObserver` generates
a fake focus move from IME point of view.)
Additionally, there is the opposite case, that is, editing host of an `<input>`
whose type is not a text control may become a text control. Therefore, this
adds new WPTs to check the handler is the text editor for the text control or
the HTML editor. The tests passed on Firefox and Chrome at least.
FYI: I guess that in this case, we need to kick `focus` event listener of the
`HTMLEditor`, but anyway, users cannot change the content because it's the
case that an atomic content is the editing host. Therefore, I don't touch
about that in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D193262
