This is needed to use the IPDLParamTraits implementation for nsIURI which is
used in part 2 of this patch series.
Differential Revision: https://phabricator.services.mozilla.com/D14434
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
This is needed to use the IPDLParamTraits implementation for nsIURI which is
used in part 2 of this patch series.
Differential Revision: https://phabricator.services.mozilla.com/D14434
--HG--
extra : moz-landing-system : lando
Alloc methods can't take arguments by move reference, whereas Recv
methods can, and we'd like to take OptionalLoadInfoArgs (at least) by
move reference. Since Init is infallible anyway, it doesn't really
matter where we do it, so move it to this separate method to pave the
way for rvalue reference OptionalLoadInfoArgs.
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
We had previously missed to call browser.updateSecurityUIForContentBlockingEvent on
onLocationChange updates, to reset the contentBlockingEvent state. This would mean that
on tab switch the contentBlockingEvent state for benign pages would still be what it was
set to on the last tracker page.
Differential Revision: https://phabricator.services.mozilla.com/D20328
--HG--
extra : moz-landing-system : lando
This patch takes the approach of keeping track of a list of nsWindowRoot
objects in the JSWindowActorService. Listeners are then maintained for
each type of actor for every nsWindowRoot.
Depends on D20012
Differential Revision: https://phabricator.services.mozilla.com/D20013
--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
The old complicated code here was working around a fundamental race in the
test. The test was trying to do the following:
1) Open a new tab. This sends an IPC message to do that and to start loading
about:blank in the tab.
2) Add a "load" listener. This sends an IPC message to add the listener.
3) Start loading the URL we really want to load. This sends an IPC message to
start the load.
There are two races here: the message from step 2 can be received before or
after the about:blank load is done, and the message from step 3 can be received
before or after the about:blank load is done. If step 2 wins the race (we add
the listener before the about:blank load is done) but step 3 loses the race
(new load starts only after the about:blank load is done), then we would get a
load event for the about:blank, not for the url we care about.
The test worked around this by having step 2 add a listener for the
"DOMDocElementInserted" event, which about:blank did not fire. Then when that
happened (indicating that the load from step 3 is now in progress), it added a
"load" listener. This fixed the race.
Bug 1528146 fixed about:blank to also fire "DOMDocElementInserted", so the test
became racy again. Now if the "DOMDocElementInserted" listener got added
_after_ the about:blank load had fired that event (which is what usually
happened), then the test passed. But if the IPC message from step 2 to add the
"DOMDocElementInserted" listener won the race against the about:blank load
firing "DOMDocElementInserted", then we added the "load" listener too early and
got the "load" event for the about:blank, not the document we cared about.
The fix is to just use the (now) existing openNewForegroundTab function which
lets us pass in a url, then wait until that URL is loaded, instead of trying to
reinvent that wheel.
There is an additional ride-along change to make openNewForegroundTab always
create a new process in this test, which is the original intent of the test but
wasn't necessarily guaranteed by the old code.
Differential Revision: https://phabricator.services.mozilla.com/D20544
--HG--
extra : moz-landing-system : lando
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
Any time we QI to nsIFrameLoaderOwner in tests, we're really accessing
a MozFrameLoader. We don't need to be doing that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19727
--HG--
extra : moz-landing-system : lando
Nika Layzell
Tarek Ziadé
Boris Zbarsky
Ciure Andrei
James Willcox
Jan de Mooij
Shane Caraveo
Gurzau Raul
Noemi Erli
Nathan Froyd
Andreea Pavel
Christoph Kerschbaumer
Johann Hofmann
Ehsan Akhgari
Andreas Farre
Henri Sivonen
Cosmin Sabou
Makoto Kato
Sylvestre Ledru
Kyle Machulis