nsContentSink::ProcessStyleLink only does something useful for CSS
stylesheets. But for those, nsXMLContentSink::HandleProcessingInstruction
already returns early before calling nsXMLContentSink::ProcessStyleLink. So
the only way that nsContentSink::ProcessStyleLink can be reached for an XML PI
is already a no-op and there's no reason to make that call.
MozReview-Commit-ID: 5XPnvoY0T56
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
Once we call DoneAddingChildren, random code of various sorts will run, which
can flush our notification state. If that happens before we've notified on our
kids, but after we've popped the element we're closing off the element stack,
we will fail to ever notify on the kids.
MozReview-Commit-ID: Ei7v5OobX8R
(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
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
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
It is a preparation for later patch which moves functions from those
classes into StyleSheet. Some of the functions are better defined in
StyleSheetInlines.h.
This commit is generated by the following command:
find . \( -name '*.h' -or -name '*.cpp' \) -not -name '*StyleSheet*' -exec sed -i -b \
-e '/^#include/ s_/\(CSS\|Servo\)StyleSheet\.h_/StyleSheetInlines.h_' \
-e '1,\_^#include "mozilla/StyleSheetInlines.h"_ ! { \_^#include "mozilla/StyleSheetInlines.h"_d }' {} +
MozReview-Commit-ID: 54H5x27Pmso
--HG--
extra : source : e4fe253a8f82c3c58e5191d6af66fb0e85f2df19
If the mathml.disabled preference is true, treat <math> and other MathML
elements as generic XML elements.
This patch disables the rendering code of MathML however preserves the
namespace so to reduce the breakage.
Original patch by: Kathy Brade <brade@pearlcrescent.com>
MozReview-Commit-ID: A2f2Q2b4eqR
--HG--
extra : rebase_source : 3c8530816727c01b68a831d560bfe16e7b02bd9d
