This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
This is a follow-up patch for bug 1392970. Since we only set CustomElementDefinition on a custom element
which is "custom", we could add more assertion to ensure that.
MozReview-Commit-ID: 2sLP53bAYVV
--HG--
extra : rebase_source : 523761aa7312ddfaaf91f79e39c44ddce5cf9335
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
We make nsContentUtils::EnqueueLifecycleCallback static so that it can be
called without a window object. To achive this, we also make
CustomElementReaction not taking a CustomElementRegistry in the constructor,
as it can call Upgrade statically.
MozReview-Commit-ID: 7xUvK0q7Eri
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
It a stateless wrapper around static methods in nsHTMLTags and nsHTMLElement,
and hence an unnecessary layer of indirection that just adds complexity and
slowness. This patch removes it, cutting almost 300 lines of code.
This requires making nsElementTable.h an exported header, to expose the
nsHTMLElement methods.
--HG--
extra : rebase_source : abbcb8e5001389affbf717092213b898673db07f
We call attributeChangedCallback in two cases:
1. When any of the attributes in the observed attribute list has changed,
appended, removed, or replaced.
2. When upgrading an element, for each attribute in element's attribute list
that is in the observed attribute list.
MozReview-Commit-ID: LKUY5ibp9RI
* * *
Bug 1334051 - Part 3: Optimize attributeChanged callbacks. r=smaug
So that the old upgrade can also work with new upgrade steps
which will be implemented in part 5-2.
MozReview-Commit-ID: IRyvAPaN19R
--HG--
extra : rebase_source : 2385608f4857401a37f76070eadb643b1016dd15
extra : histedit_source : 4f33007ed262d001782399f6f70ced0c22f47d66
1. It is possible that invoking a reaction triggers pushing a
new ElementQueue into ReactionStack (e.g., calling define() in
constructor which probably enqueue another upgrade reaction),
and the reference of ElementQueue passed to InvokeReactions
becomes invalid due to the memmove in nsTArray implementation.
I hit such problem when running
http://w3c-test.org/custom-elements/CustomElementRegistry.html test.
2. And we get another benefit from this is memmove becomes faster.
MozReview-Commit-ID: KQ86ZugqsPi
--HG--
extra : rebase_source : b5e5c6b45fa79143094f7a337386a4bb57b777be
extra : histedit_source : 70fec53d07b1f693f91db2c1870af3284a47729e
Bug 1347446 makes accessing ElementReactionQueue becomes a bit non-trival (have to get it via DocGroup).
Since bug 1359346 already refactors the creation time of CustomElementData, ReactionQueue can also be put into
CustomElementData, then we can just get ReactionQueue from Element.
MozReview-Commit-ID: D6PouDu8hkL
There are two places doing prototype setup in old upgrade,
- If definition comes after JS reflector creation, CustomElementRegistry::Upgrade will do prototype swizzling.
- If definition comes before JS reflector creation, Element::WrapObject will set up the prototype.
The later one does SubsumesConsideringDomain, but the former doesn't not.
This patch is to fix the inconsistency, i.e. the former case should also do SubsumesConsideringDomain.
MozReview-Commit-ID: G3gVsaEa0YF
--HG--
extra : rebase_source : 5e2081e470473cd1a1f642a2dc693127cb9486ca
Edgar Chen
Jonathan Watt
Sebastian Hengst
Andrew McCreight
Jessica Jong
Steve Fink
John Dai
Nicholas Nethercote
Olli Pettay
Kris Maglione
Sylvestre Ledru
Mats Palmgren
Bill McCloskey
Carsten "Tomcat" Book