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
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
Although the following patch do not use the `dom::EventTarget*` versions,
they should be available for consistency with the other `FromNode` related
utility methods.
Differential Revision: https://phabricator.services.mozilla.com/D215576
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
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
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
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
As per step 3 at "attribute change steps"[1], when the old state is in showing state and
the new state is different, we run hide popover algorithm. According to step 10 and step 11
at #hide-popover-algorithm, popover is removed from top layer. The current implementation has
covered step 3 for attribute change. We shouldn't removing popover from top layer again when
attr value is None.
[1] https://html.spec.whatwg.org/multipage/popover.html
Differential Revision: https://phabricator.services.mozilla.com/D201952
A popover can have multiple invoker buttons.
Previously, we only fired a state change event on the button which was invoked.
This meant that the cached expanded/collapsed state of any other invokers was stale.
To facilitate this:
1. Add popovertarget to DocAccessible's kRelationAttrs so that we track reverse relationships. This will also later be used for exposing relations.
2. When an Accessible is shown or hidden, if it is a popover, use RelatedAccIterator to get all the invokers and fire appropriate state change events on each of them.
3. This also means we can get rid of nsAccessibilityService::PopovertargetMaybeChanged, since this explicit notification from DOM is no longer useful.
4. Add popovertarget to LocalAccessible::AttributeChangesState so that we fire an event for the expandable/expanded/collapsed state change if appropriate when that attribute is changed.
Differential Revision: https://phabricator.services.mozilla.com/D199842
The offset* APIs use the primary frame (the table wrapper frame) to
choose an offset parent, so if we stop at the table frame we skip the
offset between the wrapper and the table boxes.
Differential Revision: https://phabricator.services.mozilla.com/D200948
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
Make it be output-only, not having that confusing in-out tab-index
parameter that is special for XUL to become focusable with
-moz-user-focus: normal. Instead, do that explicitly in
nsIFrame::IsFocusable().
Also, call it IsFocusableWithoutStyle(), since that's what it is.
Differential Revision: https://phabricator.services.mozilla.com/D195644
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
Includes only support for dynamically loading style sheets from `<link>`
elements and `Link` header fields.
The remaining support, including preloading, is completed in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D191745
This adds support for the experimental `invoketarget` and `invokeaction`
attributes, as specified in the open-ui "Invokers" explainer.
(https://open-ui.org/components/invokers.explainer/)
The `invoketarget` attribute maps to the IDL `invokeTargetElement`,
similar to `popoverTargetElement`, and the `invokeaction` is a freeform
string.
The Button behaviour checks for `invokeTargetElement` in its activation
behaviour, and dispatches an `InvokeEvent` if there is one.
This also adds some basic scaffolding for `handleInvokeInternal` which
will allow elements to provide their own invocation action algorithms.
Differential Revision: https://phabricator.services.mozilla.com/D190449
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
