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
--HG--
extra : rebase_source : ba8b6e85fb922869bbba749b4948bb4489878f22
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
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
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 replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
Based on XHR spec 6.1, if one or more event listeners are registered on the
associated XMLHttpRequestUpload object, then set upload listener flag.
Therefore, if any event listeners are added after send(), ignore them.
Fire upload.onabort and upload.onloadend when abort() called. Original code
won't fire onabort if mUploadComplete is true.
Per https://xhr.spec.whatwg.org/#request-error-steps xhr.upload.onabort fires before .onabort
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
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
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
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
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
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.
--HG--
extra : rebase_source : 7c9d2a545968a50c8ec34a3395132f0d99087058
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
Thomas Wisniewski
Chris Peterson
Boris Zbarsky
Andrea Marchesini
Nicholas Nethercote
Honza Bambas
Andrew McCreight
Shawn Huang
Eric Rahm
Bobby Holley
Masatoshi Kimura
Julian Seward
Sebastian Hengst
Bevis Tseng
Sylvestre Ledru
Carsten "Tomcat" Book
Bill McCloskey
Florian Quèze
Henri Sivonen
Chris H-C
Kershaw Chang
Christoph Kerschbaumer
Nathan Froyd