This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D20853
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
Feel free to cancel the review if you already have a patch or if you wanted another approach.
Mostly wrote this patch to make sure the DevTools patch on top of it would work.
Differential Revision: https://phabricator.services.mozilla.com/D19159
--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
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
Summary:
This test first creates a service worker and then an iframe. It expects the
iframe's first load to be through the network (and for the page's script to
fail to load). Once the page is set up and controlled by the SW, it reloads it
(a soft reload) and the script load is intercepted by the service worker and
we load a script that calls back into the test. However, there is currently no
guarantee that the service worker won't activate before the iframe load and
end up controlling the first load of the iframe.
With this patch, we delay the service worker's activation until we start
loading the iframe, allowing the first load to always be uncontrolled, thereby
resolving the race.
Reviewers: asuth
Reviewed By: asuth
Bug #: 1517406
Differential Revision: https://phabricator.services.mozilla.com/D15637
--HG--
extra : rebase_source : ff63b131b1a395289cda85ec4b46daa3022b08b4
Summary:
Most of these tests pass now, so enable them and only disable the tests that
don't pass. This should make driving these tests to all passing easier to do
and prevent regressions.
Reviewers: asuth
Reviewed By: asuth
Bug #: 1517406
Differential Revision: https://phabricator.services.mozilla.com/D15636
--HG--
extra : rebase_source : 252502cb5d8d43fd8a2e7b50a97ea4d64e2ef07d
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
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.
I would have loved to get rid of ServiceWorkerContainer.getScopeForUrl in
favor of just doing things in the chrome script, but it's a pain to make it
work in both the parent-intercept and non- cases. Once we get rid of
non-parent-intercept, we should just remove this test-only API.
Differential Revision: https://phabricator.services.mozilla.com/D15218
--HG--
extra : moz-landing-system : lando
Make consistent use of MozPromise chaining where possible and remove unnecessary refcount.
Differential Revision: https://phabricator.services.mozilla.com/D14029
--HG--
extra : moz-landing-system : lando
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
Currently, we are required to fire updatefound in three cases:
* When a "soft" update finds an update.
* When a call to ServiceWorkerRegistration.update finds an update.
* When ServiceWorkerContainer.register registers a ServiceWorker.
In the first case, there are no requirements on the timing of the event. For
the second two cases, however, the promise returned by update or register
needs to resolve before updatefound is dispatched. We hack around the first
case by explicitly counting the calls to update and only dispatching
updatefound when the final promise resolves. In the case of SWC.register, the
ServiceWorkerRegistration object might not even exist when it notices that we
need to fire updatefound, which suggests that we need some code to tell it
when to fire the event; except that in the soft update case, there is no
obvious place to do so. So, the easiest way to resolve this is to have the
parent process tell the ServiceWorkerRegistration when to fire updatefound
itself. This way, we don't rely on any tricky timing and everything is
consistent with itself.
Differential Revision: https://phabricator.services.mozilla.com/D13368
--HG--
extra : moz-landing-system : lando
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/D13073
--HG--
extra : moz-landing-system : lando
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/D13073
--HG--
extra : moz-landing-system : lando
