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
Do not report malloc size of CacheIOThread::mThread, because it can be reported by ThreadsReporter.
--HG--
extra : rebase_source : b077f80a82c5df70f1b3f267f7718f1ad7f94ea1
This patch changes all size limits in CacheObserver to kilobytes. The same unit is used at most places when checking these limits. This avoids uint32_t overflow when converting to bytes and back.
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
For consumers which have an origin string, currently they need to parse it into
a URI before they can call testPermission(). Internally, in the common case this
nsIURI* argument will be immediately converted back into the same origin string
in PermissionKey::CreateFromURI(). This means that the cost of parsing the
original origin string will effectively end up being wasted in the common case.
This patch adds an API that allows the consumer to test a permission using the
origin string directly, and only parse it into an nsIURI when necessary, thereby
avoiding this overhead.
Differential Revision: https://phabricator.services.mozilla.com/D15543
--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
Due to member alignment rules on 64-bit platforms, nsLoadGroup has more
unused space than it should. Shuffling members around a little to fill
in holes should make nsLoadGroup somewhat smaller.
We apparently had this for internal extension hooks that couldn't be
depended on externally...but now that interfaces aren't exposed to
addons, we can remove this no-op interface entirely.
We only write to this variable and never read it. The whole
nsPILoadGroupInternal interface looks like it could go away, actually;
we'll do that in a subsequent patch.