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
When a test crashes, the harness skips all of the remaining tests in the
directory. That means that with crashes skipped, we now try to run a whole lot
more tests than we did before, and a lot of them fail under Fission.
This patch adds annotations to the new failures that show up after part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38726
--HG--
extra : rebase_source : 292157039c88fc615f5de41679e96e72766ac4db
Connection already saves the list of Session, so it is more natural
to save it only once there and instead directly close the connections
from Target. Each connection is going to cleanup all related sessions.
I also stop automatically registering the session to the connection from Session constructor,
it felt not explicit enough.
Differential Revision: https://phabricator.services.mozilla.com/D37045
--HG--
extra : moz-landing-system : lando
* TabObserver is rather an helper class of Targets rather than RemoteAgent.
Targets is the class which holds all the targets and reports about their
creation and destructor. It feels legitimate to have it directly integrate
with TabObserver.
* To better sort of the files. i.e. avoid having "random files" in /remote/
I'm renaming and moving TabObserver according to its usage.
* We were emitting "connect" and "disconnect" event when a target was created
or destroyed. But this is misleading as there is no connection to anything
being made. Only later, a CDP client might connect to a target HTTP endpoint
and initiate a connection. These events are making this hard to understand
that the connection actually happens when Target.handle is called.
Differential Revision: https://phabricator.services.mozilla.com/D37043
--HG--
rename : remote/WindowManager.jsm => remote/targets/TabObserver.jsm
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
This helps sharing a single implementation of how the JSON objects
are read and written from/to the WebSocket connection.
Also, by delegating the command calls to the Session via `Session.execute`
and expecting a promise with a resolution or rejection, we make error
handling of command calls clearer and unified.
Differential Revision: https://phabricator.services.mozilla.com/D37046
--HG--
extra : moz-landing-system : lando
Connect and disconnect in misleading here as a target aren't connected/disconnected,
but instead, being unregistered and destroyed. The fact that they are "disconnected"
is a side effect of this destruction. Also note that a Target is never "connected",
it is only a Connection and its related sessions which really are connected to a remote client.
Differential Revision: https://phabricator.services.mozilla.com/D37042
--HG--
extra : moz-landing-system : lando
The test was relying on selectionchange events fired on an input text element.
This event is behind a pref, flip the pref to true during the test in order to make it
pass on all channels
Differential Revision: https://phabricator.services.mozilla.com/D36330
--HG--
extra : moz-landing-system : lando
Andreas Tolfsen
Coroiu Cristina
Henrik Skupin
Brindusan Cristian
Mohit Singh
Maja Frydrychowicz
Kris Maglione
shindli
Noemi Erli
Daniel Varga
Gurzau Raul
Mihai Alexandru Michis
Sylvestre Ledru
danwalsh99
Oana Pop Rus
JaStenson
Ryan VanderMeulen
Thomas
Cosmin Sabou
Anny Gakhokidze
Kashav Madan
Nicholas Nethercote
Narcis Beleuzu
Julian Descottes
Andreea Pavel
Boris Zbarsky
Alexandre Poirot
Sebastian Hengst
Victor Porof
Andrey Lushnikov