We'll want to use this event to inject scripts before other scripts run
in XUL documents. It already fires in HTML documents.
MozReview-Commit-ID: 7FW0R8r9o9G
--HG--
extra : rebase_source : 28fe9b6a4bcbb6ecf8966a0c059d867bf66285bf
The patch for bug 1387427 made us keep the source content in an array and we don't insert
it into the document anymore. The code for xslt-param and xslt-param-namespace should look
in the source content array instead of the document.
--HG--
extra : rebase_source : bbf4c6ab66357b3d7fe3f91fefc040d0a19578f5
We want to create the source fragment before trying to use it in URIUtils::ResetWithSource.
The testcase triggers an assertion related to unbalanced onload blocking/unblocking,
fixing that by blocking onload on the new document we're setting in OnTransformDone and
unblocking onload on the old document.
--HG--
extra : rebase_source : 8bbdb9ce6a38dc6b76d13dfb2c3c7d67f78ecefe
The DOMMatrix.cpp changes are because it was sneaking in headers via another
unified file.
MozReview-Commit-ID: GPp9WOywI5D
--HG--
rename : dom/base/nsGenericDOMDataNode.cpp => dom/base/CharacterData.cpp
rename : dom/base/nsGenericDOMDataNode.h => dom/base/CharacterData.h
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
Also remove duplicate import from the XMLMonoPrint sheet (unnamed default sheets
stay applied when switching to alternates, only named are unapplied).
Additionally fix some regressions from bug 379683:
* top-level collapsed and uncollapsible elements weren't monospaced in monospace
style.
* top-level uncollapsible elements weren't indented.
* there was an extra space between PIs and their expander control.
Based on prototype by bgrins.
MozReview-Commit-ID: 2Pikm41FMWY
--HG--
extra : rebase_source : a8fb7dd9f40a267e93d50342c51728dcc98c4918
Also remove duplicate import from the XMLMonoPrint sheet (unnamed default sheets
stay applied when switching to alternates, only named are unapplied).
Additionally fix some regressions from bug 379683:
* top-level collapsed and uncollapsible elements weren't monospaced in monospace
style.
* top-level uncollapsible elements weren't indented.
* there was an extra space between PIs and their expander control.
Based on prototype by bgrins.
MozReview-Commit-ID: 2Pikm41FMWY
--HG--
extra : rebase_source : 56cacffcbdcefc47548ba1b123bcfb1551941ab9
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
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
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
nsXBLBinding::ChangeDocument calls UnbindAnonymousContent
which calls UnbindFromTree on the content so any frames must be
destroyed before that to maintain the invariant that frames are
destroyed before unbinding.
MozReview-Commit-ID: 8Icj7zqpuZS
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
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
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
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
Chris Peterson
Boris Zbarsky
Emilio Cobos Álvarez
Dorel Luca
Brian Grinstead
Andrew McCreight
Sebastian Hengst
Tristan Bourvon
Christoph Kerschbaumer
Peter Van der Beken
Ian Moody
Coroiu Cristina
Florian Quèze
Josh Matthews
Adrian Wielgosik
Kris Maglione
Cosmin Sabou
Brindusan Cristian
Ehsan Akhgari
Andrea Marchesini
Jonathan Watt
Ryan VanderMeulen
Dave Townsend
Mats Palmgren
Nicholas Nethercote
Catalin Badea
Chung-Sheng Fu
Thomas Nguyen
Bobby Holley
Dragana Damjanovic dd.mozilla@gmail.com
Kyle Machulis
Bevis Tseng
Sylvestre Ledru