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
1. Handle the "terminate the ongoing fetch" cases in the spec-text
- do not CloseRequest in Abort/Open if the state is UNSENT or DONE).
- ensure we don't fire extra events after terminating this way
if a stray OnDataAvailable happens afterward.
2. Ensure that status/statusText correctly return 0/"" to mimic the
spec's "set response to a network error" steps (requires special
handling in the worker XHR code).
MozReview-Commit-ID: 5kMyGgD7uUU
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 is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
This is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
With nsIDocument::IsScriptTracking, we know that whether a script is a tracking script. If the XHR is created by a tracking script, we want to lower the priority of the http channel.
This patch is to label the runnables dispatched to main thread of the
content process.
The major changes in xhr are to replace DispatchTo{Current,Main}Thread and
replace NS_DispatchToCurrentThread with |mWorkerPrivate->DispatchToMainThread|
in which a DocGroup-specific EventTarget on main thread for worker.
