1. This patch somehow sets a "breakpoint" in ProcessPartialContent() and ProcessNotModified() to really stop doing things after ProcessPartialContent() and ProcessNotModified(), when the channel is suspended.
2. Add a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D13277
--HG--
extra : moz-landing-system : lando
The goal in this patch is to notify "http-on-before-connect" and "http-on-modify-request" observers in DoAuthRetry and also handle the case when the channel is canceled or suspended by observer.
Differential Revision: https://phabricator.services.mozilla.com/D10741
--HG--
extra : moz-landing-system : lando
In 1404608, the OS was revealed in both the HTTP User-Agent
header and to JavaScript code via navigator.userAgent. To avoid
leaking the OS inside each HTTP request (which many web servers
log), always use the Windows 7 OS value in the desktop User-Agent
header. We continue to allow access to the actual OS via JavaScript,
since doing so improves compatibility with web applications such
as GitHub and Google Docs.
This is an uplift of Tor's 26146
This adds a way to simulate failed network connections, allowing the addition of test coverage that would otherwise not be available. This is used in the Downloads tests to ensure that failures at the network level are handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D15522
--HG--
extra : rebase_source : 2597b27de5213b0322520cefafe10a197d0d3b83
For navigation: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
For images: image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
for style: text/css,*/*;q=0.1
Anything else: */*
Turns out we also produced an error instead of a warnings.
Good that we added those test \o/
Differential Revision: https://phabricator.services.mozilla.com/D15659
--HG--
extra : moz-landing-system : lando
There are 2 parts of the patch:
1) we should not try to use websockets over h2 if we already know that they are not supported.
2) make sure that we clean up websockets waiting for the settings frame when we close a h2 connection. (the part 1) will fix the issue, this part is only to be 100% that we some how do not retrigger the issue)
Differential Revision: https://phabricator.services.mozilla.com/D15296
--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 helper code is currently unused, and presents a pretty significant
footgun for any JS object which implements nsIPropertyBag itself.
When those objects are first queried to nsIWritablePropertyBag, they behave as
expected, returning the JS-implemented nsIPropertyBag methods. But when
they're first queried to nsIPropertyBag, they use the XPCWrappedNative stubs,
which don't behave as expected.
Differential Revision: https://phabricator.services.mozilla.com/D15235
--HG--
extra : rebase_source : 02942592dc8c4efcc1190610448a46593faa5703
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
Since we need the loadInfo to set up the IPDL connection, we move the logic to
do so from HttpChannelChild::AsyncOpen to HttpChannelChild::SetLoadInfo
via InitIPCChannel.
It would have been nicer to do so in HttpChannelChild::Init, but
I ran into issues with view-source channels, which required an ugly hack.
Also note that RemoteChannelExists() preserves the existing contract - it is
true between asyncOpen and onStopRequest - but the name is slightly off, as
the channel has already been open by the time we call asyncOpen. We will fix
this in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D12419
--HG--
extra : moz-landing-system : lando
