Most of these elements are simple to support.
One slightly tricky item was <input type=date>, as testing indicates that the
front-end code usually (consistently?) hides the picker using setPickerState(),
which does not end up calling closeDateTimePicker() as might be expected.
So to properly track the open/closed state, I had to add a SetDateTimePickerState
webidl method, rather than just patching into the existing Open/Close calls.
Differential Revision: https://phabricator.services.mozilla.com/D234093
Most of these elements are simple to support.
One slightly tricky item was <input type=date>, as testing indicates that the
front-end code usually (consistently?) hides the picker using setPickerState(),
which does not end up calling closeDateTimePicker() as might be expected.
So to properly track the open/closed state, I had to add a SetDateTimePickerState
webidl method, rather than just patching into the existing Open/Close calls.
Differential Revision: https://phabricator.services.mozilla.com/D234093
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
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
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
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
The main changes of the new algorithm are
* Make the dialog focusing steps look at sequentially focusable elements instead of any focusable element.
* Make the dialog element itself get focus if it has the autofocus attribute set.
* Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.
Spec PR (merged): https://github.com/whatwg/html/pull/8199
Differential Revision: https://phabricator.services.mozilla.com/D181263
The main changes of the new algorithm are
* Make the dialog focusing steps look at sequentially focusable elements instead of any focusable element.
* Make the dialog element itself get focus if it has the autofocus attribute set.
* Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.
Spec PR (merged): https://github.com/whatwg/html/pull/8199
Differential Revision: https://phabricator.services.mozilla.com/D181263
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Keith Cirkel