This facilitates monitoring the navigation response.
The remaining work for moving navigation-related code into
the parent process should be done in Bug 1612538.
Differential Revision: https://phabricator.services.mozilla.com/D71654
There are needs to delay the execution of code on the main thread
until the next tick of the event loop has happened.
Differential Revision: https://phabricator.services.mozilla.com/D71291
Tests are mixing APIs between each other, which this patch removes.
Also error messages have been adjusted for both methods to
be on par with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D67840
--HG--
extra : moz-landing-system : lando
Evaluating `document.open` + `write` + `close` triggers the `readyState`
to change to "loading". Puppeteer, for example, relies on a seeing an
"init" life cycle event in that case for their `Page.setContent` method.
Also move "Page.loadEventFired" to be triggered by an actual "load"
instead of "pagehide", which we don't see after a `document.write`.
Differential Revision: https://phabricator.services.mozilla.com/D67702
--HG--
extra : moz-landing-system : lando
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
It's uncelar if this should be mapped to CRASH or ERROR, but
it probably doesn't matter much; it seems to be a fatal error
that terminates the rest of the run, but we don't get a stack.
I arbitarily chose CRASH.
Differential Revision: https://phabricator.services.mozilla.com/D66753
--HG--
extra : moz-landing-system : lando
Use mozlog to handle logging from the `mach puppeteer-test`
command. This makes the output compatible with treeherder and allows
generating error summaries that can be used by the push-health
feature.
Presently the integration is based on parsing the output from mocha
with regex since that's easy to implement without digging into the
many layers of js code too much. In time it might make sense to
replace this with a custom output formatter integrated into mocha
itself.
We also add the ability to store and use expected results, so that we
are able to detect regressions even when not all test are passing. The
format of expected results is Dict[String, List[String]], where the
keys are test names and the values are lists of statuses. If the list
has more than one value the remaining values are treated as possible
intermittent statuses.
The updated expected statues can be generated by passing the
--write-results flag to the mach command.
Differential Revision: https://phabricator.services.mozilla.com/D65700
--HG--
extra : moz-landing-system : lando
Values like NaN, Infinity, -Infinity are not serializable and have
to be returned via the unserializable property and not as value.
This patch also adds the type and description properties as
Puppeteer tests require, but leaves out support for
BigInt (bug 1615360).
Differential Revision: https://phabricator.services.mozilla.com/D62778
--HG--
extra : moz-landing-system : lando
This introduces a -v[v] flag to the "./mach puppeteer-test" command
for increasing the logging verbosity of the remote agent in Gecko.
This can be used as a shorthand for --setpref="remote.log.level=<level>".
A single -v will enable log messages up to debug level, and two
-vv will enable all log messages up to trace level.
Differential Revision: https://phabricator.services.mozilla.com/D58619
--HG--
extra : moz-landing-system : lando
The "./mach puppeteer-test" command now takes a new flag,
--enable-fission, which will set the fission.autostart preference to true.
Differential Revision: https://phabricator.services.mozilla.com/D58512
--HG--
extra : moz-landing-system : lando
Puppeteer accepts an environmental variable EXTRA_LAUNCH_OPTIONS
that is a JSON encoded object as a string, containing additional
configuration to use when running tests.
This takes an extraPrefsFirefox key which is an object
mapping preference names to values. This is extracted in
remote/test/puppeteer/lib/Launcher.js:390 and later written to a
fresh profile in :515.
It appears remote/mach_commands.py has left out the "Firefox" appendix.
Differential Revision: https://phabricator.services.mozilla.com/D58511
--HG--
extra : moz-landing-system : lando
Bug 1605722 already added those helpers to the global head.js file.
As such they can be removed from the target's head.js file.
Differential Revision: https://phabricator.services.mozilla.com/D58163
--HG--
extra : moz-landing-system : lando
This feature is experimental and not required to get implemented
on our end as of now. As such adding a place-holder will be enough.
Differential Revision: https://phabricator.services.mozilla.com/D59006
--HG--
extra : moz-landing-system : lando
Similarly to bug 1603451, the name of the function passed to the
specialised add_agent_task() is lost because of the anonymous
function wrapper inside.
Differential Revision: https://phabricator.services.mozilla.com/D58967
--HG--
extra : moz-landing-system : lando
When remote.log.level is Log.Level.Info or above, verbose logging
is enabled and we pretty-print JSON payloads in requests to the
HTTPD in JSONHandler.
This patch matches the behaviour of the JSONHandler logging, where
JSON payloads are logged to stdout with special formatting before
being transmitted across WebSocket connections.
Differential Revision: https://phabricator.services.mozilla.com/D58506
--HG--
extra : moz-landing-system : lando
The CDP protocol expects consistent types to be returned. By filtering
out null values and strings of zero length we break this promise.
Differential Revision: https://phabricator.services.mozilla.com/D58620
--HG--
extra : moz-landing-system : lando
Upgrading to http 0.2 will give us bytes ^0.5 which removes
a dependency on iovec. iovec is problematic for us because it
depends on a version of winapi that does not compile on Windows AArch64.
The effect of this should be that the remote agent is now possible
to compile on Windows AArch64.
Differential Revision: https://phabricator.services.mozilla.com/D58765
--HG--
extra : moz-landing-system : lando
nsIHttpServer.registerPathHandler() is designed to take null as
the second argument to unregister path handlers. This saves us
from having to modify its internal state, and fixes a minor TODO
in the remote agent initialisation code.
Differential Revision: https://phabricator.services.mozilla.com/D58605
--HG--
extra : moz-landing-system : lando
We were lacking documentation on how to run inidividual Puppeteer
tests. It turns out this is not possible yet to do on a per-file
basis, like other test harnesses.
Instead, suggest use of fdescribe()/fit() and recommend some useful
Mocha flags.
Differential Revision: https://phabricator.services.mozilla.com/D58618
--HG--
extra : moz-landing-system : lando
This reverts the commit:
git: d640ab64b993431099cd9205297bfff464d76927
hg: 9f6327c0d8298ec58a6c9f8d51526872d01d765e
Differential Revision: https://phabricator.services.mozilla.com/D58503
--HG--
extra : moz-landing-system : lando
This reverts the commit:
git: d640ab64b993431099cd9205297bfff464d76927
hg: 9f6327c0d8298ec58a6c9f8d51526872d01d765e
Differential Revision: https://phabricator.services.mozilla.com/D58503
--HG--
extra : moz-landing-system : lando
Errors that arise from use of the protocol, for example by the client
passing in the wrong argument or an operationg being unsupported, are
returned to the client. Since these are not inherent implementation
problems there is no point to double-logging them in the server.
This is a left-over from when the remote agent was in a prototype
stage and we couldn't always rely on the Puppeteer client to
interact with Firefox correctly.
Differential Revision: https://phabricator.services.mozilla.com/D58508
--HG--
extra : moz-landing-system : lando
When remote.log.level is Log.Level.Info or above, verbose logging
is enabled and we pretty-print JSON payloads in requests to the
HTTPD in JSONHandler.
This patch matches the behaviour with JSON payloads being transmitted
across WebSocket connections.
Differential Revision: https://phabricator.services.mozilla.com/D58506
--HG--
extra : moz-landing-system : lando
Moving the JSON payload sanitisation function to Protocol.jsm
means we can share it across modules.
The patch also adds new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58505
--HG--
extra : moz-landing-system : lando
This patch adds basic support for retrieving cookies,
which means that it returns the cookies for the currently
active target.
Hereby it has the following limitations:
1. It does not walk the frame tree, and as such only returns
the cookies from the top-level frame. Support for that will
be added once frames can correctly be handled, which means
once support for the JSWindowActor API has been landed.
2. The "urls" parameter is not supported because it is
unclear right now what it actually does. More investigation
is necessary before any implementation can happen.
3. There is no support for the file:// protocol yet.
4. Dot domains aren't taken care of yet.
Differential Revision: https://phabricator.services.mozilla.com/D57614
--HG--
extra : moz-landing-system : lando
The browser-chrome test name is derived from the function name.
The function name of the original task is lost when wrapped inside
the add_task() override in remote/test/browser/head.js.
This fixes the problem by rewriting the taskFn name on the new wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D57079
--HG--
extra : moz-landing-system : lando
The documentation for the overridden add_task() is quite poor.
Document it as to not confuse new developers why it is behaving
differently to the default bc add_task().
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D57078
--HG--
extra : moz-landing-system : lando
This patch implements the IO.read() method to allow
reading streams for files and blobs.
Therefor all the methods in the IO domain need a registry
for streams. Those have to be stored globally because
they need to be kept existent across different client
connections.
Differential Revision: https://phabricator.services.mozilla.com/D55968
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Adds browser-chrome tests for the main entry point of the remote
agent, nsIRemoteAgent.
add_agent_task() wraps add_plain_task() (which again wraps the
original add_task()) so we can ensure that the agent isn't listening
before a test runs, and that any modified state such as preferences
is reset afterwards.
The tests rely heavily on the assumption that nsIRemoteAgent.close()
behaves as a no-op when the server is not listening.
This patch is a follow-up to bug 1590828.
Differential Revision: https://phabricator.services.mozilla.com/D55456
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This does not support the grantUniversalAccess parameter.
It just creates a new execution context.
Differential Revision: https://phabricator.services.mozilla.com/D55169
--HG--
extra : moz-landing-system : lando
As noted in Bug 1602083, the CDP viewer implies that execution context management
is independent of the Runtime domain, which makes sense with the behaviour of methods
like Page.createIsolatedWorld.
This is a first step in that direction.
Depends on D55168
Differential Revision: https://phabricator.services.mozilla.com/D56279
--HG--
extra : moz-landing-system : lando
Dismantle the assumption that there is one ExecutionContext per
inner window and generate a fresh id for each ExecutionContext
rather than reusing the inner window id.
Differential Revision: https://phabricator.services.mozilla.com/D55168
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Now that nsIRemoteAgent propagates errors correctly to Rust we can
report errors back to the user when something terrible happens.
The effect of all this is that the startup handler can stop Firefox
when the remote agent fails to listen.
Differential Revision: https://phabricator.services.mozilla.com/D55178
--HG--
extra : moz-landing-system : lando
The nsIRemoteAgent interface introduced with bug 1543115 did
not change the exceptions thrown internally by the class. To ensure
better interaction with consumers over XPIDL we should ensure the
JS implementation throws NS exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D55177
--HG--
extra : moz-landing-system : lando
As nsIHttpServer.registerPathHandler now checks that the path is
not empty we can drop our pre-check when target-created is handled.
If target.path does happen to be empty an error is printed to the console.
Differential Revision: https://phabricator.services.mozilla.com/D55161
--HG--
extra : moz-landing-system : lando
Interfaces exposed over XPIDL cannot be marked async, otherwise their
return values get lost. This patch makes nsIRemoteAgent.listen()
synchronous by removing the use of async/await.
Unfortunately Rust does not yet support deserialising promises sent across
XPIDL, documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1512319.
In an effort to retain the original API internally the function
now returns a promise. This means the function can be awaited in
JS only, which we make use of in remote/test/browser/head.js.
Differential Revision: https://phabricator.services.mozilla.com/D55173
--HG--
extra : moz-landing-system : lando
Interfaces exposed over XPIDL cannot be marked async, otherwise their
return values get lost. This patch makes nsIRemoteAgent.close()
synchronous by removing the use of async/await.
Unfortunately Rust does not yet support deserialising promises sent
across XPIDL, so in an effort to retain the original API internally
the function now returns a promise. This means the function can be
awaited in JS only, which we make use of in remote/test/browser/head.js.
Differential Revision: https://phabricator.services.mozilla.com/D55172
--HG--
extra : moz-landing-system : lando
Adds browser-chrome tests for the main entry point of the remote
agent, nsIRemoteAgent.
add_agent_task() wraps add_plain_task() (which again wraps the
original add_task()) so we can ensure that the agent isn't listening
before a test runs, and that any modified state such as preferences
is reset afterwards.
The tests rely heavily on the assumption that nsIRemoteAgent.close()
behaves as a no-op when the server is not listening.
This patch is a follow-up to bug 1590828.
Differential Revision: https://phabricator.services.mozilla.com/D55456
--HG--
extra : moz-landing-system : lando
Now that the security review in bug 1542229 and the follow-up work
that came out of it is complete, we should go ahead and flip the
remote.enabled preference.
This patch causes the remote agent to be available to users on the
Firefox Nightly release channel. This meansusing --remote-debugger
will no longer cause a fatal error
Differential Revision: https://phabricator.services.mozilla.com/D55137
--HG--
extra : moz-landing-system : lando
As long as we do not validate incoming messages against the
Chrome DevTools JSON schema, all incoming commands would be
executed. To prevent clients from changing internal data by
calling internal commands (prefixed with "_"), deny their
execution.
Differential Revision: https://phabricator.services.mozilla.com/D55411
--HG--
extra : moz-landing-system : lando
With bug 1543115 we saw a rewrite of the startup code path in the
remote agent. It forgot to update the build instructions to mention
that changes to the Rust code requires you to have a full build available.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D55130
--HG--
extra : moz-landing-system : lando
This moves the Chromium remote debugging protocol implementation
in Firefox from using sessionstore-windows-restored to a new
remote-startup-requested notification observer.
This change makes it possible for applications to explicitly decide
at which stage it is considered safe to initialise the remote agent
listener. It is safe to emit this notification at any time since
the observer for it is only registered after the --remote-debugger
flag is is used.
The remote debugger only supports Firefox, so this patch does not
take care of GeckoView/Android.
Differential Revision: https://phabricator.services.mozilla.com/D54485
--HG--
extra : moz-landing-system : lando
This event is currently sent for each and every message,
and as such duplicates every log entry as displayed when
having the Puppeteer debug logs turned on.
Until we can fix it to behave correctly, it should be
disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54273
--HG--
extra : moz-landing-system : lando
Full SHA-1: 2fff4ea08428842ad252a72bb3af30ab107fbd6c
Contains two commits reverting the stderr workaround, now that bug
1590826 prints to stderr.
Differential Revision: https://phabricator.services.mozilla.com/D54271
--HG--
extra : moz-landing-system : lando
This bootstraps the remote agent from Rust so that we have access
to write to stderr using the eprintln!() macro. There is a future
intention to expand Rust usage in the remote agent by delegating
CDP and WebDriver Bi-Di protocol schema validation to serde.
The Rust port is faithful to the JS version in terms of functionality,
and in some places improves on the original design by enforcing
a strict division between flag handling code on one hand, and the
remote agent server on the other.
Differential Revision: https://phabricator.services.mozilla.com/D50289
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
Adds an XPIDL interface for the remote agent which we will later use to
initialise and start it from a new command-line handler written in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50287
--HG--
extra : moz-landing-system : lando
Crafting nsIURIs in Rust is complicated. Allow RemoteAgent.listen()
to accept both strings and nsIURIs when called in JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D50286
--HG--
extra : moz-landing-system : lando
When calling RemoteAgent.listen() across XPIDL the function is run
asynchronously. In order to find out when the remote agent has started
listening we introduce a "remote-listening" system observer notification.
Differential Revision: https://phabricator.services.mozilla.com/D50285
--HG--
extra : moz-landing-system : lando
Although it currently makes no difference, we should ensure the
required preferences are set sooner, in case any of the internal
remote agent features depend on it.
Because we also cannot control when the nsICommandLineHandler for
the remote agent is invoked, setting it sooner rather than later,
seems a lot safer.
Differential Revision: https://phabricator.services.mozilla.com/D50283
--HG--
extra : moz-landing-system : lando
close() is meant to be failsafe in the sense that it should be
possible to call without side-effects.
We are currently setting up a lot of state in listen() that is not
cleaned up if the server eventually fails to start. Calling close()
when this happens will ensure any state listen() has accrued is reset.
Differential Revision: https://phabricator.services.mozilla.com/D50282
--HG--
extra : moz-landing-system : lando
Having init() as a separate function leads to inconsistencies about
how the required state is checked.
init() prevents the remote agent from being loaded when the
remote.enabled preference is false or it is attempted loaded into a
child process, but listen() already manipulates state before these
checks are run. This is probably not the intention, but an easy
mistake to make when the code flow is not crystal clear.
Since we never have a need to call init() independently, this patch
merges init() into listen().
Differential Revision: https://phabricator.services.mozilla.com/D50281
--HG--
extra : moz-landing-system : lando
All other XPCOM component manifests are named components.conf and
this makes the remote agent's conform with those.
It will also become apparent in a later patch in this changeset
that we need to register two XPCOM components: one implementing
the remote agent service, and one for handling command-line arguments.
Differential Revision: https://phabricator.services.mozilla.com/D50280
--HG--
rename : remote/RemoteAgent.conf => remote/components.conf
extra : moz-landing-system : lando
This bootstraps the remote agent from Rust so that we have access
to write to stderr using the eprintln!() macro. There is a future
intention to expand Rust usage in the remote agent by delegating
CDP and WebDriver Bi-Di protocol schema validation to serde.
The Rust port is faithful to the JS version in terms of functionality,
and in some places improves on the original design by enforcing
a strict division between flag handling code on one hand, and the
remote agent server on the other.
Differential Revision: https://phabricator.services.mozilla.com/D50289
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
Adds an XPIDL interface for the remote agent which we will later use to
initialise and start it from a new command-line handler written in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50287
--HG--
extra : moz-landing-system : lando
Crafting nsIURIs in Rust is complicated. Allow RemoteAgent.listen()
to accept both strings and nsIURIs when called in JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D50286
--HG--
extra : moz-landing-system : lando
When calling RemoteAgent.listen() across XPIDL the function is run
asynchronously. In order to find out when the remote agent has started
listening we introduce a "remote-listening" system observer notification.
Differential Revision: https://phabricator.services.mozilla.com/D50285
--HG--
extra : moz-landing-system : lando
Although it currently makes no difference, we should ensure the
required preferences are set sooner, in case any of the internal
remote agent features depend on it.
Because we also cannot control when the nsICommandLineHandler for
the remote agent is invoked, setting it sooner rather than later,
seems a lot safer.
Differential Revision: https://phabricator.services.mozilla.com/D50283
--HG--
extra : moz-landing-system : lando
close() is meant to be failsafe in the sense that it should be
possible to call without side-effects.
We are currently setting up a lot of state in listen() that is not
cleaned up if the server eventually fails to start. Calling close()
when this happens will ensure any state listen() has accrued is reset.
Differential Revision: https://phabricator.services.mozilla.com/D50282
--HG--
extra : moz-landing-system : lando
Having init() as a separate function leads to inconsistencies about
how the required state is checked.
init() prevents the remote agent from being loaded when the
remote.enabled preference is false or it is attempted loaded into a
child process, but listen() already manipulates state before these
checks are run. This is probably not the intention, but an easy
mistake to make when the code flow is not crystal clear.
Since we never have a need to call init() independently, this patch
merges init() into listen().
Differential Revision: https://phabricator.services.mozilla.com/D50281
--HG--
extra : moz-landing-system : lando
All other XPCOM component manifests are named components.conf and
this makes the remote agent's conform with those.
It will also become apparent in a later patch in this changeset
that we need to register two XPCOM components: one implementing
the remote agent service, and one for handling command-line arguments.
Differential Revision: https://phabricator.services.mozilla.com/D50280
--HG--
rename : remote/RemoteAgent.conf => remote/components.conf
extra : moz-landing-system : lando
The method under the Network domain is a redirect to
Emulation only. It might be deprecated, but that's unclear
in the current documentation.
Differential Revision: https://phabricator.services.mozilla.com/D52929
--HG--
extra : moz-landing-system : lando
This patch implements setting the user agent only. Support for
accepted language, and platform will be done in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D52831
--HG--
extra : moz-landing-system : lando
By using loadSubScript() instead of injecting a script node
into the hidden window, the content of chrome-remote-interface.js
can be cached. Only the first load will take about 150ms, each
test afterward will only have to spend about 30ms in getCDP().
Differential Revision: https://phabricator.services.mozilla.com/D53073
--HG--
extra : moz-landing-system : lando
Using the minimized version reduces the file size from 880kB
to 550kB, which means lesser data to load and to cache.
Imported revision: f412dd1ed0028bcf9116918879b99924039d52e2
Differential Revision: https://phabricator.services.mozilla.com/D53072
--HG--
extra : moz-landing-system : lando
This takes advantage of the browser-selection patch proposed to Puppeteer.
A --product option allows choice between 'firefox' and 'chrome'.
Puppeteer takes care of profile creation for Firefox. Additional Puppeteer
Launcher options can be passed along with --setopt.
Depends on D52313
Differential Revision: https://phabricator.services.mozilla.com/D52314
--HG--
extra : moz-landing-system : lando
This sub-test has races which were exacerbated by making data: URLs load asynchronously. Disable it until the race can be resolved.
MANUAL PUSH: bustage fix on a CLOSED TREE
--HG--
extra : amend_source : 76c3d8486213b5829615059587f44f0db93b9041
The actual screenshot data should be returned via the "data"
property of an object. Also the data URL prefix has to be
stripped off, so that only the base64 encoded data will be
transmitted.
Differential Revision: https://phabricator.services.mozilla.com/D52144
--HG--
extra : moz-landing-system : lando
This implements an all-or-nothing insecure sweeping override that
bypasses security exceptions when loading documents with invalid
or otherwise bad TLS certificates.
Differential Revision: https://phabricator.services.mozilla.com/D50838
--HG--
extra : moz-landing-system : lando
Currently when browser chrome tests are failing the open tabs, client,
and Remote Agent will never be closed, and as such each failing test
causes massive memory leaks.
Therefore the teardown logic needs to be moved out of the tests into
the "add_task()" function. Only that way we can make sure to run
all the clean-up steps independent of the test success state.
Differential Revision: https://phabricator.services.mozilla.com/D50233
--HG--
extra : moz-landing-system : lando
To ensure that the CDP server connection is always closed after a
test even when it is failing, its lifetime has to be handled inside
the "add_task" function.
Currently if a test fails all the registered events and observer
notifications are getting leaked. This patch ensures that all of
those events and notifications are getting unregistered.
Differential Revision: https://phabricator.services.mozilla.com/D50232
--HG--
extra : moz-landing-system : lando
Due to some obvious bugs in the code of TabObserver.jsm the registered
targets for each of the window's tabs haven't been unregistered when
the window has been closed.
It has the effect that when closing the Remote Agent the browsingContext
of the tab target, which has to be destroyed, cannot be retrieved.
Instead an error is raises, because the underlying frameLoader actually
doesn't exist anymore.
Given that "TabClose" events aren't fired when the window closes,
those have to be emulated.
Differential Revision: https://phabricator.services.mozilla.com/D50231
--HG--
extra : moz-landing-system : lando
This also fixes the intermittent timeout on Windows debug by
moving the event checks to a separate test.
Differential Revision: https://phabricator.services.mozilla.com/D49995
--HG--
rename : remote/test/browser/browser_input_dispatchKeyEvent.js => remote/test/browser/input/browser_dispatchKeyEvent.js
rename : remote/test/browser/browser_input_dispatchKeyEvent_race.js => remote/test/browser/input/browser_dispatchKeyEvent_race.js
rename : remote/test/browser/browser_input_dispatchMouseEvent.js => remote/test/browser/input/browser_dispatchMouseEvent.js
rename : remote/test/browser/doc_input_dispatchKeyEvent_race.html => remote/test/browser/input/doc_dispatchKeyEvent_race.html
rename : remote/test/browser/doc_input_events.html => remote/test/browser/input/doc_events.html
extra : moz-landing-system : lando
To allow for multiple client connections the ChannelEventSinkFactory
class only has to be registered once. By reference counting consumers
of this factory it can be made sure to only unregister it once no
consumers of the factory exist anymore.
With this refactoring we basically allow multiple client connections
to our CDP implementation.
Differential Revision: https://phabricator.services.mozilla.com/D49329
--HG--
extra : moz-landing-system : lando
Similar to all the other test jobs also the Puppeteer jobs should
not run in headless by default. Instead it should be an opt-in.
Differential Revision: https://phabricator.services.mozilla.com/D48823
--HG--
extra : moz-landing-system : lando
In order to get the browser_page_frameNavigated.js and
browser_page_frameNavigated_iframe.js tests passing under Fission
we can load the test resources from the same site origin as the
initial test document. This avoids a content browser remoteness
change, which strictly speaking is not what the tests are testing.
Differential Revision: https://phabricator.services.mozilla.com/D47897
--HG--
extra : moz-landing-system : lando
This makes it possible to for mach to determine which test types
are likely to be relevant.
Differential Revision: https://phabricator.services.mozilla.com/D37014
--HG--
extra : moz-landing-system : lando
We vendor the Puppeteer library, but not its dependencies.
When "npm install" is called in remote/test/puppeteer/, it puts
its dependencies under remote/test/puppeteer/node_modules/ and
generates a remote/test/puppeteer/package-lock.json file. We do
not want these to be checked in.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D37010
--HG--
extra : moz-landing-system : lando
Introduces "./mach puppeteer-test" command for running the Puppeteer
tests against the remote agent. This has to be a top-level command
because the automatic test detection system in mach does not allow
us to delegate to a subcommand such as "./mach remote puppeteer-test".
The tests run against a fork of Puppeteer with hotfixes needed for
it to work with the CDP implementation in Firefox. This fork is
located at https://github.com/andreastt/puppeteer/tree/firefox, and
vendored under remote/test/puppeteer/ in a previous commit in this series.
Differential Revision: https://phabricator.services.mozilla.com/D37009
--HG--
extra : moz-landing-system : lando
Puppeteer is licensed under the Apache-2.0 license.
No code from Puppeteer gets included in Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D37008
--HG--
extra : moz-landing-system : lando
Introduces "./mach remote vendor-puppeteer" for vendoring the
Puppeteer client without dependencies into remote/test/puppeteer/.
The particular checkout of Puppeteer is
https://github.com/andreastt/puppeteer/tree/firefox, which contains a
couple of hotfixes we need for the client to work with the Firefox
implementation of CDP.
The remote agent targets a specific version of Puppeteer, so it is
not suitable for this to be vendored under third_party/. We also
wouldn't want other code in central to accidentally use a patched fork.
The vendoring process is not part of "./mach vendor" because it does
not yet have Node.js support, and implementing that for mach is outside
the scope of getting the Puppeteer tests running with the remote agent.
Differential Revision: https://phabricator.services.mozilla.com/D37007
--HG--
extra : moz-landing-system : lando
This makes prefs definition simpler, more consistent, and less error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D41324
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
For many browser-chrome (bc) tests is does not matter what the
document is, as long as it is does not cause state to bleed over
from the previous test.
For these cases this patch introduces a shorthand, setup(), which
calls setupForURL(url) with an empty document generated by toDataURL("").
Differential Revision: https://phabricator.services.mozilla.com/D40216
--HG--
extra : moz-landing-system : lando
Per the URL standard, we should avoid talking about URIs (and indeed
URI, URN, et al.) since the term only serves to mislead.
Differential Revision: https://phabricator.services.mozilla.com/D40215
--HG--
extra : moz-landing-system : lando
For many browser-chrome (bc) tests is does not matter what the
document is, as long as it is does not cause state to bleed over
from the previous test.
For these cases this patch introduces a shorthand, setup(), which
calls setupForURL(url) with an empty document generated by toDataURL("").
Differential Revision: https://phabricator.services.mozilla.com/D40216
--HG--
extra : moz-landing-system : lando
Per the URL standard, we should avoid talking about URIs (and indeed
URI, URN, et al.) since the term only serves to mislead.
Differential Revision: https://phabricator.services.mozilla.com/D40215
--HG--
extra : moz-landing-system : lando
Some local adaptions have been made, but this is mostly functionally
equivalent.
Differential Revision: https://phabricator.services.mozilla.com/D39687
--HG--
extra : moz-landing-system : lando
Introduces helper function, toDataURL(), that takes a document
extract and produces a data URL with the necessary properties for
Gecko to recognise it as an HTML document with the correct media type.
This has the benefit that HTML fragments and tags such as < and > are
encoded correctly, which is an obvious safety-win, and subsequently
that documents can be created on-the-fly with minimal code.
It will be possible to extend this function for other document types,
such as XHTML, XML, and even binary formats, as needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D39686
--HG--
extra : moz-landing-system : lando
If the contextId parameter is omitted when calling Runtime.evaluate,
the expression will be performed in the context of the currently
inspected page.
Differential Revision: https://phabricator.services.mozilla.com/D36823
--HG--
extra : moz-landing-system : lando