This reverts commit 82b2e13b45.
Revert "Bug 2038124 - Optimize setting attributes on non-custom HTML elements from parser. r=smaug"
This reverts commit 2d1ee1cd69.
This reverts commit 9dd3f6b595.
Revert "Bug 2038124 - Optimize setting attributes on non-custom HTML elements from parser. r=smaug"
This reverts commit b1774ce65e.
Currently, our editor and document viewer manage `Selection` state and
ranges within their `focus`/`blur` event listeners. However, UI Events
defines that the events should be fired after the focus move finished
[1][2]. Therefore, we need to move the handlers to
`EventTarget::PreHandleEvent` or the event listener of the event target
parent of the window (in the capturing phase of the default event group).
Otherwise, a web content's event listener runs before we maintain the
`Selection`. This patch moves the handlers to
`nsGlobalWindowInner::PreHandleEvent`.
Currently, there are 3 event listeners which maintain the `Selection`.
`nsDocViewerFocusListener`:
This maintains the active `nsFrameSelection` and the display of the
last focused selection only when the document node gets focus. This
patch removes this class and move the code into new static methods of
`nsFrameSelection`.
`HTMLEditor::OnFocus`:
This activates the document `nsFrameSelection` and collapses `Selection`
to the focused element if `Selection` ranges are not in the focused
editing host. This does it even if a text control gets focus even though
the focused `TextEditor` will handle the further user inputs.
`TextEditor::OnFocus`:
This activate the independent `nsFrameSelection`.
These handlers run in the following order:
1. `nsDocViewerFocusListener`
2. `HTMLEditor`
3. `TextEditor`
Therefore, `nsGlobalWindowInner::PreHandleEvent` handles all of them
within this order.
Note that `TextEditor::OnFocus` is now called after `HTMLInputElement`
or `HTMLTextAreaElement` prepares the further `change` event
dispatching. After applying this patch, their `PreHandleEvent` will do
that. Then, `nsGlobalWindowInner::PreHandleEvent` will run because
`PreHandleEvent`s are called in the bubbling phase order. Therefore, the
handling order shouldn't be changed.
1. https://w3c.github.io/uievents/#event-type-focus
2. https://w3c.github.io/uievents/#event-type-blur
Differential Revision: https://phabricator.services.mozilla.com/D292335
Currently Element has the SHADOW_ROOT_IS_DETAILS_SHADOW_TREE flag, which
determines if the element is a Details element and allows branching for specific
shadow root operations, such as getting the slot names, and handlers for slot
changed and unslotted.
This change refactors this to be more generic: switching this branching for
virtual methods instead, while dropping the flag. It also then co-locates the
Details specific shadow root operations into HTMLDetailsElement.cpp.
This will allow us to introduce more element specific Shadow Root behaviours,
such as those for the `<select>` element.
Differential Revision: https://phabricator.services.mozilla.com/D295337
This reverts commit 85b2d0d3dd.
Revert "Bug 2022763 - Propagate owner global from input element to DOM files properly. r=dom-core,win-reviewers,smaug,gstoll"
This reverts commit ff40c521b2.
Since bug 2017711, this code is called from frame construction for text
inputs. There's no guarantee that DoneCreatingElement has been called
yet.
Differential Revision: https://phabricator.services.mozilla.com/D286739
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
Speedometer3's TodoMVC-jQuery hits basically the worst case of my
change, which is creating a hidden text input per row. That causes tons
of extra time spent in BindToTree and so on because we now create the
shadow tree for all of those. It is specially bad because the shadow
tree is particularly expensive (see bug 2017005).
For now, keep creating the <input> shadow tree lazily from layout, but
with a key difference: Once created, we keep it around.
This should still allow us to fix the reframing issues linked from
bug 2016280 and hopefully won't be too painful. It is a bit annoying
that TextControlElement can't rely on the shadow tree existing, but that
seems ok...
Of course preferred outcome is to make shadow trees less costly. Most of
the cost is still allocation of the slots, afaict from the profiles.
Differential Revision: https://phabricator.services.mozilla.com/D284039
Otherwise we eagerly create a shadow root for HTML inputs created by the
parser even if they end up not needing one.
This shows up in speedometer. But also, should we maybe make the parser
bind the element after setting the attributes rather than before?
Differential Revision: https://phabricator.services.mozilla.com/D283423
There's still a ton of things that can be cleaned up after this, but
this setup is nicer.
For now, editor keeps getting set-up / torn down on BindToFrame. Seems
all that could be untangled, but step by step.
The preview stuff and placeholder can just be created on demand now,
rather than requiring frame reconstruction.
Also, nsSearchControlFrame and co no longer do anything of interest, so
move the still relevant bits elsewhere and remove them.
test_bug1248459.html is removed because it messes with the editor
selection using SpecialPowers, in a way such that it crosses shadow
boundaries, and messes up the selected state triggering debug asserts.
test_focus_docnav.xhtml now triggers a different code-path because of
the shadow root (rather than the frame tree traversal). Keep it working
for now by replacing it with something that isn't a shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D282953
It uses DoneAddingChildren / DoneCreatingElement, and nsXULElement also
does this.
Otherwise we can get into weird situations because the consumers might
not expect this.
We have some tests for parser-specific behavior like restoration in
test_prototype_document.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D283432
It uses DoneAddingChildren / DoneCreatingElement, and nsXULElement also
does this.
Otherwise we can get into weird situations because the consumers might
not expect this.
We have some tests for parser-specific behavior like restoration in
test_prototype_document.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D283432
Daniel Holbert