There are two changes being made here:
* In call sites where we know both origin arguments are equal,
we will call a specialized version of the function which
avoids the origin equality check.
* We avoid calling into the generic printf structure and build
the result string manually.
Differential Revision: https://phabricator.services.mozilla.com/D19245
--HG--
extra : moz-landing-system : lando
The only implementation of nsIURI which has a GetHostPort() method which can
succeed is nsStandardURL, which implements nsIURL. Other implementations
either do not implement nsIURL (so in the old version, they would bail out
early) or they do, but their GetHostPort() method returns an error code
unconditionally (so in the old version, they would bail out later). Hence,
this patch doesn't change the semantics of the code.
Depends on D15545
Differential Revision: https://phabricator.services.mozilla.com/D15546
--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.
Add a WindowProxyHolder type and generate binding code that takes or returns it whenever
the WebIDL refers to the WindowProxy type. This patch just makes the WindowProxyHolder
hold a strong reference to a nsPIDOMWindowOuter.
Differential Revision: https://phabricator.services.mozilla.com/D12650
--HG--
extra : moz-landing-system : lando
This is a non-functional fix (since int converts to bool implicitly)
which reverts a mistake I made when rebasing the fix in bug 1509047.
Differential Revision: https://phabricator.services.mozilla.com/D15026
--HG--
extra : moz-landing-system : lando
Some channels such as the dummy channel created inside
CookieServiceParent::RecvSetCookieString() do not have an
nsIParentChannel interface, but we must be careful to not run the
content process code path for them.
Differential Revision: https://phabricator.services.mozilla.com/D13519
--HG--
extra : moz-landing-system : lando
Calling this function is just a waste of time since we will check
third-partiness a few statements further down.
Differential Revision: https://phabricator.services.mozilla.com/D13500
--HG--
extra : moz-landing-system : lando
Calling this function is just a waste of time since we will check
third-partiness a few statements further down.
Differential Revision: https://phabricator.services.mozilla.com/D13500
--HG--
extra : moz-landing-system : lando
This makes a difference for doubly nested trackers that are embedded
under the same top-level tracker, with a third-party origin in the
middle, as the test case in this commit has set up things.
The test case here fails without the code changes.
Differential Revision: https://phabricator.services.mozilla.com/D12855
--HG--
extra : moz-landing-system : lando
It can be expected for the top-level storage area principal to be
null here, so we shouldn't warn about it.
Differential Revision: https://phabricator.services.mozilla.com/D12835
--HG--
extra : moz-landing-system : lando
This is needed for the LocalStorage Next-Generation project which sends storage
notifications only to content processes with an existing LocalStorage object.
I cannot write a test for this, because the current localStorage all works fine.
