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.
Thunderbird uses DOMParser from C++ for now. They should ideally migrate that into JS, but we can give them something that works for the moment.
MozReview-Commit-ID: C4D6QuFdbn8
We always have one now. So we can remove all the codepaths that attempted to
handle the !mPrincipal case.
We can also remove the nsContentUtils::IsSystemPrincipal(mPrincipal) codepaths,
because that can never happen: DOMParser::Constructor never creates a DOMParser
with a system principal.
MozReview-Commit-ID: EUrGoiI0o3u
In our test suite, we only run into two calls to this constructor with a system
principal, and both are in test code.
After this, calling the WebIDL constructor from system code is _almost_
equivalent to creating by contract. The one difference is that the resulting
DOMParser (and the documents it creates) will have its script handling object
set to the global the constructor came from instead of being null.
MozReview-Commit-ID: Fe2yMeqoYnB
Some DOM unit tests rely on being able to parse XUL via DOMParser. That was allowed due to them calling init() with a system subject principal. It can be more narrowly allowed by adding an explicit setter for being able to parse XUL/XBL.
MozReview-Commit-ID: 3h0WWGHmYOn
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
Now that what we use to decide whether a document is styled by Servo are only
prefs and the doc principal, we don't need to inherit the style backend type,
since unless the pref has changed, the result will be the same.
MozReview-Commit-ID: KBmeBn1cRne
The old code doesn't work because mScriptHandlingObject is a nsWeakPtr,
which cannot be casted to nsPIDOMWindowInner directly.
Since scriptHandlingObject is a strong reference to the same object, we
can just try casting that.
MozReview-Commit-ID: JRBs5N6xxc0
--HG--
extra : rebase_source : cd0237553198182b00ff9c667a17271b23464567
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
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
There's a better way to create null principals than
do_CreateInstance("@mozilla.org/nullprincipal;1"). Let's do that and
save ourselves some XPCOM overhead.
Sylvestre Ledru
Ryan Hunt
Jonathan Kingston
Alex Gaynor
Dorel Luca
Emilio Cobos Álvarez
Andrea Marchesini
Adrian Wielgosik
Boris Zbarsky
Tom Ritter
Chris Peterson
Xidorn Quan
Bobby Holley
Ehsan Akhgari
Dave Huseby
Jonathan Hao
Yoshi Huang
Kyle Huey
Nathan Froyd
Kit Cambridge
Andrew McCreight