The tests currently running against chromium do not expect the content blocking
to be enabled. So, to prevent breaking cookies/requests being done by the tests,
disable it by default when running the agent.
Differential Revision: https://phabricator.services.mozilla.com/D31993
--HG--
extra : moz-landing-system : lando
The node program (puppeteer) and/or the agent itself, will close Firefox brutaly
in some cases. So that when we reopen Firefox, the safe mode popup will be shown,
asking the user if he prefers to start in safe mode.
But that break the automation as we expect Firefox to be opening the browser window as usual.
Differential Revision: https://phabricator.services.mozilla.com/D31992
--HG--
extra : moz-landing-system : lando
Debugger.Object's class isn't "Object" for DOM Elements.
Instead, it is specific to each element tag name.
Differential Revision: https://phabricator.services.mozilla.com/D31084
--HG--
extra : moz-landing-system : lando
Puppeteer parses stderr looking for the regular expression
^DevTools listening on (ws:\/\/.*)$. For Puppeteer to be able
to connect to Firefox, we need to change the line we print slightly
to conform with this expression.
The remote agent also uses Log.jsm to print it, but we cannot rely
on logging always being enabled, e.g. if remote.log.level is set
to Warn or above. For this reason we should use dump().
The patch also instantiates the main target before starting the HTTPD.
Differential Revision: https://phabricator.services.mozilla.com/D30913
--HG--
extra : moz-landing-system : lando
This allows improving all tests exceptions without requiring
any specific to be done in each tests.
I'm also moving a few imports to head.js to share the most into head.js.
Differential Revision: https://phabricator.services.mozilla.com/D29414
--HG--
extra : moz-landing-system : lando
Start the `TabObserver` from `RemoteAgent.listen` in order to prevent
having the tests to manually start it.
Start it from `listen` instead of `init` as we do stop the `TabObserver` from
`stop` and `stop` is the reverse of `listen`, not the reverse of `init`.
Differential Revision: https://phabricator.services.mozilla.com/D29412
--HG--
extra : moz-landing-system : lando
Before landing the remote agent in Firefox Nightly, we had to disable
remote/test/browser/browser_cdp.js because it caused a permafailure
on debug due to a memory leak. We thought the problem was limited
to this specific test, but over the weekend two more intermittent
leaks were discovered:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1546850
* https://bugzilla.mozilla.org/show_bug.cgi?id=1547303
Until we have had time to investigate and plug the leak, we will
disable all the browser-chrome tests on all debug platforms.
Differential Revision: https://phabricator.services.mozilla.com/D29181
--HG--
extra : moz-landing-system : lando
As detailed in https://bugzilla.mozilla.org/show_bug.cgi?id=1546945,
there is a memory leak in the remote agent that is triggered by
code paths in the remote/test/browser/browser_cdp.js browser-chrome test.
It is possible the memory leak is related to holding onto a reference
of the XPConnect C++ object nsSocketTransportService, but this has
yet to be confirmed.
This patch disables the test in question on debug builds, where
we run reference counting leakchecks, in order to get the remote
agent enabled in default Firefox Nightly builds.
Thanks-to: Alexandre Poirot <poirot.alex@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D28872
--HG--
extra : moz-landing-system : lando
We can reconstruct the CDP error and print a better error message
using RemoteAgentError. This is better than the current output,
which in a lot of cases will be "CDP Exception: [object Object]".
A possible future improvement to this involves extending the CDP
protocol to send the individual components of the error individually,
so that we don't have to parse the string.
Differential Revision: https://phabricator.services.mozilla.com/D28703
--HG--
extra : moz-landing-system : lando
There are two concepts of targets in CDP: the target web document,
and the Target domain. The remote/targets/ subfolder is related
to the first, which should have bugs filed under Remote Protocol ::
Agent, covered by the preceding rule.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D28689
--HG--
extra : moz-landing-system : lando
Patch unfortunately has to add a few domain stubs so that mach does
not complain about not finding any files associated with these new
bug components.
Differential Revision: https://phabricator.services.mozilla.com/D28688
--HG--
extra : moz-landing-system : lando
The tests are instrumented to automatically set the remote.enabled
preference as part of their manifests. In the case of xpcshell,
it is also technically not need it as they do not trigger the
command-line-handler.js code path.
DONTBUILD
There are two concepts of targets in CDP: the target web document,
and the Target domain. The remote/targets/ subfolder is related
to the first, which should have bugs filed under Remote Protocol ::
Agent, covered by the preceding rule.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D28689
--HG--
extra : moz-landing-system : lando
FatalError uses Services.startup.quit and this is apparently fine
to run in an xpcshell test with an optimised build, but not with
debug builds where it causes MOZ_CRASH() to be hit.
This removes test_FatalError so that we can run test_Error.js on try.
Differential Revision: https://phabricator.services.mozilla.com/D28705
--HG--
extra : moz-landing-system : lando
The remote debugger mochitest browser-chrome tests do not have to
be run in a separate subsuite. Removing the subsuite condition
will make them appear as part of the normal M-bc* jobs on try.
Differential Revision: https://phabricator.services.mozilla.com/D27932
--HG--
extra : moz-landing-system : lando