This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
nsContentUtils::NS_NewXULOrHTMLElement will call into
CustomElementRegisty::RegisterCallbackUpgradeElement, which keeps
the newly created element, allowing RunCustomElementCreationCallback
to upgrade them after the callback runs.
It is unclear if this changes the order of constructor executions,
but even so it should not affact our use case.
MozReview-Commit-ID: LWTn7B35aBv
--HG--
extra : rebase_source : 15382431f34dd887c14142ff47337e8d1eec74ef
extra : source : 47058a61951c2974514e41e316e5370cfa4f9d8b
This would help in the case where it is safe to run script in-place and
the CustomElementDefinition is available before the function exits.
This fixes the tests changed.
MozReview-Commit-ID: Ays91W94WZm
--HG--
extra : rebase_source : 6b0f1f90de9a6bfd7db577f1fb0e76564c3627e7
extra : source : 47c62a1e2f268e1be24c3fddfc006c3ad45ba4ac
Nodes copied from DOMParser document fragment would need to be
created with the proper custom element data.
CustomElementRegistry::IsCustomElementEnabled() is changed to allow
it to run in the test document.
MozReview-Commit-ID: 4GACDR8FIc7
--HG--
extra : rebase_source : 39da41dd1ca56bf62043418c503c526e2895254f
1) The passed-in constructor is already same-compartment with the passed-in
aCx, so there is no need to enter its Realm to work with it.
2) aCx is already in the compartment of constructorProtoUnwrapped when we do
JS_WrapValue on rootedv, which is initialized to constructorProtoUnwrapped.
That JS_WrapValue call is not needed.
This check is already done by the dictionary init method. This function just
makes us do extra non-spec get operations.
For now this introduces more failures due to bug 1419323 and the spec issue at
<https://github.com/whatwg/html/issues/3580>. The tests testing for that stuff
were passing due to exceptions getting thrown from CheckLifeCycleCallbacks.
This patch enables us to specify a custom element type with |is| attribute
or property when creating a XUL element. Because non-dashed names are valid
custom element names in XUL (bug 1446247), other checks has to modified
accordingly.
The checks I am settling with are
1) Forbids the custom built-in element names to be a non-dashed name.
2) Forbids the custom built-in element to extend a dashed built-in element name.
This also ensures the custom built-in element types don't take on the same
name as the element name it extends.
MozReview-Commit-ID: GCQ9RnfvvrC
--HG--
extra : rebase_source : 2fa13742525d2107580d50872ff5b0fc42539498
extra : source : 2dc5513660d78a4de4801109140743ffc9297f71
This patch creates a chrome-only method
customElements.setElementCreationCallback() so that custom elements migrated
from XBL bindings doesn't have to be define()'d on document loading. With this
method, we will set callbacks and the platform will get back to us when it
encounters a matched custom element type -- and the callback will load the
relevant script.
It's important to note that the callback runs after construction of the first
element; it will be upgraded when it's being appended.
MozReview-Commit-ID: 80z72zwXRlf
--HG--
extra : rebase_source : 826188e56bb0b167d1e5bafb7d2a487a32bd9dfa
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
The webconsole UI generates a large number of scrollbars, and considering their children as
potential Custom Elements causes a slowdown when setting innerHTML="" when devtools closes.
MozReview-Commit-ID: 2QCcXCnTHA2
--HG--
extra : rebase_source : 5226e5689195a047ebcb9903b4565df13b6b1aa0
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : 735688061116c633b816f4f9d488712408df11a5
extra : source : 794ee6857d83dfe0b18629c12e96a622fc899586
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : b9632de82cf79c1df15be09fadf1d25817c8a894
extra : amend_source : 235a76453d1d6782903d5051ee8e234b965dcc36
Since we are dealing with the element (nodeInfo->LocalName() and NameAtom() are the same value),
we could use nodeInfo->NameAtom() instead.
MozReview-Commit-ID: 4vIBDEM1Nwv
--HG--
extra : rebase_source : 150d5ea982363eb2ef4c5039fae67be1e08884ba
The CustomElementUpgradeReaction and CustomElementCallbackReaction are only used inside CustomElementRegistry.cpp,
so we don't need to expose them in header file.
MozReview-Commit-ID: 9lYwHeFIODi
--HG--
extra : rebase_source : 099821b680b171b0c354c34ebd91ba5963536dc1
They are used for old spec, and we don't need them after removing document.registerElement
MozReview-Commit-ID: EqzB1PJJtrg
--HG--
extra : rebase_source : 5eaa1343bc749d172eb782e063d74099f856f9da
Jeff Gilbert
Olli Pettay
Miko Mynttinen
arthur.iakab
Emilio Cobos Álvarez
Timothy Guan-tin Chien
Margareta Eliza Balazs
Boris Zbarsky
Jan de Mooij
Brian Grinstead
Andreea Pavel
Dave Townsend
Blake Kaplan
Csoregi Natalia
Edgar Chen
Edgar Chen