properly update XHR status when one is aborted because of an NS_BINDING_ABORTED confition such as window.stop()
Differential Revision: https://phabricator.services.mozilla.com/D22852
--HG--
extra : moz-landing-system : lando
This will mean that in places like the tight loop in GetTypeIndex()
we would no longer require calling strlen() on the input type argument
once per loop iteration.
Depends on D20236
Differential Revision: https://phabricator.services.mozilla.com/D20237
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This is needed because early in a content process's lifecycle, NeckoParent may
not have been created yet. This leads to issues when trying to redirect into a
fresh process which hasn't performed network loads yet. By sending the message
over PContent, we can be sure the APIs are available.
Differential Revision: https://phabricator.services.mozilla.com/D15608
--HG--
extra : moz-landing-system : lando
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.
This needs to add a few of includes in other places which were relying on the
massive (now gone) list in nsDocument.h.
I also needed to move an AnimationTimeline destructor out of line because it
relied on dom::Animation being defined, yet Animation.h includes
AnimationTimeline.h, so include hell.
Differential Revision: https://phabricator.services.mozilla.com/D15366
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
This is a complete rewrite of the interface while maintaining the same APIs.
Each ID is fully-contained within a single object, does not require a finalizer,
and is cheap to create.
Beyond using reserved slots, this code avoids using custom ClassOps, instead
preferring Symbol.hasInstance and eager constants.
One major change which occurred in this patch was the move from storing a nsCID
to storing the ContractID for JSCID objects. This eliminates the need for the
'refreshCID' method, and hopefully shouldn't have performance implications.
If we discover that there are performance problems there, we can look into
stashing the CID, and re-introduce 'refreshCID', despite its surprising
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D2286
Rather than adding a native type for nsID objects in WebIDL, this patch just
takes the approach of switching consumers over to using 'any' and calling the
APIs defined in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2283
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
extra : intermediate-source : 7b7fa6ab2229e358666d0b0855adcfe6bd8199c4
extra : histedit_source : 6dae3cdd2834fc39ba547520cc6016ce4496cc08
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 158eb53174faa028edeebaf5970c123ba359a3e5
extra : intermediate-source : ebdca743668ce014c1cb9adfa00c1220256d357c
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 614b8f5ac2a3ae9a1027c989d37aeba1026f886a
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Disable dom.xhr.standard_content_type_normalization for now due to webcompat issues
Differential Revision: https://phabricator.services.mozilla.com/D8789
--HG--
extra : moz-landing-system : lando
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time.
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
have XHRs adjust content type of uploads per spec using the MIME Sniffing standard
Differential Revision: https://phabricator.services.mozilla.com/D5969
--HG--
extra : moz-landing-system : lando
The old code assumes that it's OK to use nsAString::BeginWriting() to write
past the string's logical length if the string has enough capacity. This is
bogus, because the string doesn't know of data written past its logical
length.
The BulkWrite API has been created precisely for this purpose and allows
orderly capacity-aware low-level writes to the string.
MozReview-Commit-ID: BYQHl8Z9Fbd
Differential Revision: https://phabricator.services.mozilla.com/D3886
--HG--
extra : moz-landing-system : lando
The old code assumes that it's OK to use nsAString::BeginWriting() to write
past the string's logical length if the string has enough capacity. This is
bogus, because the string doesn't know of data written past its logical
length.
The BulkWrite API has been created precisely for this purpose and allows
orderly capacity-aware low-level writes to the string.
MozReview-Commit-ID: BYQHl8Z9Fbd
Differential Revision: https://phabricator.services.mozilla.com/D3886
--HG--
extra : moz-landing-system : lando
* Drop the decoder when it finishes regardless of who called it.
* Match criteria for having mDecoder process EOF from OnStopRequest to
the criteria used for eager decoding in StreamReaderFunc.
* Process EOF when decoding lazily.
* Get rid of the useless mResponseCharset field.
MozReview-Commit-ID: 7oJwyKQYP8K
Differential Revision: https://phabricator.services.mozilla.com/D3591
--HG--
extra : moz-landing-system : lando
Most of the change is just making the responseType wpt run on workers and
annotating the resulting failures.
The change to the initial value of mResponseType is a drive-by fix for an
easy-to-fix issue the test caught. There is a corresponding mochitest fix to
fix our incorrect test for the behavior.
--HG--
rename : testing/web-platform/tests/xhr/responsetype.html => testing/web-platform/tests/xhr/responsetype.any.js
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
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
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
The renaming here is like this:
SetStringBuffer -> SetKnownLiveStringBuffer
SetEphemeralStringBuffer -> SetStringBuffer
SetOwnedString -> SetKnownLiveString
SetOwnedAtom -> SetKnownLiveAtom
This should make it clearer what the lifetime expectations are on the caller side.
MozReview-Commit-ID: ERHbB3r6paN
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
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.
Raise the urgent-start flag in the ClassOfService when the Fetch and XHR are
triggered by user input events. The urgent-start classification will tell the
network requests scheduler to perform it with the highest priority and also
ignoring any parallelism or overall connection limits.
MozReview-Commit-ID: 2YavWbuFaln
--HG--
extra : rebase_source : 40f41d1a4b9e323c0cf5710c6d5f2a1e45e93076
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.
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
Otherwise, if a tab is closed when we have a request pending, we'll
end up leaking the page forever, due to CC optimizations.
MozReview-Commit-ID: E5NC0jxWCur
--HG--
extra : rebase_source : ac9b068dbf7166daf90d4143a190e7caa03aa88e