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
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
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI