(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
nsHtml5Atoms are very similar to dynamic nsAtoms. This patch removes the former
in favour of the latter, which leaves nsAtom as the only subclass of nsIAtom.
nsAtom::mKind is still used to distinguish dynamic atoms from HTML5 atoms, and
the HTML5 parser still uses manual memory management to handle its HTML5 atoms.
nsHtml5AtomEntry::mAtom had to be changed from an nsAutoPtr to a raw pointer
because nsAtom's destructor is private.
MozReview-Commit-ID: 1pBzwkog3ut
--HG--
extra : rebase_source : fbb819e527cb30606348da9ce3eede62e00fb936
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
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
When triggering an iframe load or starting to parse a document for an iframe, the main thread may often have some time before the new page has been created. Try to trigger CC/GC slice at such point in order to avoid collector later when page is already executing its JS
--HG--
extra : rebase_source : 806df0af1dbaefb1761134eca0bb7c6ade6ac1a9
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
Per mixed-content-blocked spec, [1], <img srcset> and <picture> should
be blocked. However we still fetch <img srcset> and <picture> in image
preload, because they are fetched with contentPolicyType
TYPE_INTERNAL_IMAGE_PRELOAD and won't be rejected by nsMixedContentBlocker.cpp.
So I updated the image preloading code, and use the type TYPE_IMAGESET
if the image request is for <picture> or <img srcset>, otherwise for
normal image load we still use TYPE_INTERNAL_IMAGE_PRELOAD.
[1]: https://w3c.github.io/webappsec-mixed-content/#should-block-fetch
4. Return allowed if one or more of the following conditions are met:
request’s type is "image", and initiator is not "imageset".
5. Return blocked.
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
When preloading style link in <head>, we used speculative referrer policy which is
delievered from meta tag and ignored the referrerpolicy attribute.
We should use referrerpolicy attribute with the higher priority
MozReview-Commit-ID: 1rQmBV01jvV
Our current machinery for enabling stylo requires a docshell - if there isn't
one, we default to the Gecko style system.
When getComputedStyle operates on an element without a presshell, it uses the
caller's presshell instead. If the element has previously been styled with
one style system (but no longer has a presshell), and the caller uses a
different style backend, using the caller's style system can cause crashes when
we pull bits of cached data off the DOM (like cached style attributes).
So we want to throw when window.getComputedStyle(element) is called for a
(window, element) pair with different style backends (which is what the next
patch in this bug does).
However, that causes a few failures where stylo-backed documents try to do
getComputedStyle on an XHR document (which, without a docshell, will use the
gecko style system).
So this patch does some work to propagate the creator's style backend into
various docshell-less documents. This should allow both chrome (which uses gecko)
and content (which uses stylo) to use getComputedStyle on the response document
for XHRs they create.
Note that the second patch in this bug will make
chromeWin.getComputedStyle(contentObj) throw. If we discover code that does
that, we can just make it invoke the content's getComputedStyle method over Xrays.
MozReview-Commit-ID: 5OsmHJKq5Ui
This patch is mainly to make IdleTaskRunner reusable by nsHtml5TreeOpExecutor.
The only necessary work to that purpose is to remove the dependency of
sShuttingDown, which was a static variable in nsJSEnvironment.cpp.
The idea is to have a "MayStopProcessing" as a callback for the consumer to
return sShuttingDown.
In addition to sShuttingDown, we use std::function<bool()> as the runner
main callback type.
MozReview-Commit-ID: FT2X1unSvPS
--HG--
extra : rebase_source : 3fe2d4f597f53e9a90f3dc8d5009df04240534ba
extra : intermediate-source : 41f6715c344ce26f7820cecb2544db8c50dca796
extra : source : 042f10937305e34245bdaf75dcb816db7738254e
Kris Maglione
Kyle Machulis
Henri Sivonen
Nicholas Nethercote
Catalin Badea
Olli Pettay
Sebastian Hengst
Alphan Chen
Chris Peterson
John Dai
Andrew McCreight
Chung-Sheng Fu
Michael Layzell
Yoshi Huang
Eric Rahm
Honza Bambas
Sylvestre Ledru
Phil Ringnalda
Josh Matthews
Thomas Nguyen
Bobby Holley
Emilio Cobos Álvarez
Ryan VanderMeulen
Henry Chang