The previous approach wasn't quite sound, because it makes the frame
constructor receive the WillBeRemoved after the flat tree has already
changed.
Instead, what do you think about something like this? This creates a
very simple wrapper over an array, but special-cases removals from the
front, and uses it for TreeOrderedArray and also AssignedNodes...
It could be polished (in particular there are a few places where an
Span::IndexOf operator could be beneficial and so).
Differential Revision: https://phabricator.services.mozilla.com/D277301
The previous approach wasn't quite sound, because it makes the frame
constructor receive the WillBeRemoved after the flat tree has already
changed.
Instead, what do you think about something like this? This creates a
very simple wrapper over an array, but special-cases removals from the
front, and uses it for TreeOrderedArray and also AssignedNodes...
It could be polished (in particular there are a few places where an
Span::IndexOf operator could be beneficial and so).
Differential Revision: https://phabricator.services.mozilla.com/D277301
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
ElementInternal implements nsIFormControl and QueryInterface HTMLElement to a
nsIFormControl would return its associated ElementInternal instead.
Differential Revision: https://phabricator.services.mozilla.com/D125211
nsGenericHTMLFormElement doesn't implement nsIFormControl now as HTMLElement would
inherit it to be able to be added into HTMLFormElement and HTMLFieldSetElement and
support some common form feature.
So some places that call the nsIFormControl method on nsGenericHTMLFormElement
directly would need to queryInterface it to nsIFormControl first, this should be
fine as those places are not in a hot path.
Differential Revision: https://phabricator.services.mozilla.com/D124788
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The container of a radio group is the form, if it belongs to a form, or the
document object otherwise.
When moving a radio out of a form, we should add it back to a radio group.
Similary, before moving the radio to a form, we should remove it from the
original radio group.
MozReview-Commit-ID: 22WsEhz2SXH
The web platform tests changes are just a cherrypick of
https://github.com/w3c/web-platform-tests/pull/2926 so I don't have to add
failure annotations until the next test uplift.
I've audited our uses of nsIFormControl, and this patch looks to me like it
preserves existing behavior in all but the following cases:
1) nsXBLPrototypeHandler::DispatchXBLCommand, the case of scrolling when space
is pressed while something inside a <label> is focused. We used to not scroll
in this situation; I think this is a bug, so I'm changing that behavior to
scroll instead.
2) In Accessible::RelationByType for the RelationType::DEFAULT_BUTTON case,
when mContent is a <label> we used to return its form's default submit element.
Now we will just return Relation().
Emilio Cobos Álvarez