Check that the Host header is set and that the host and port are local
or match the address that the WebDriver server is running on.
Differential Revision: https://phabricator.services.mozilla.com/D83499
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
The "webSocketUrl" capability offers an opt-in
mechanism for WebDriver HTTP implementations to
make use of WebDriver BiDi, the bi-directional
protocol based on a WebSocket connection.
If the used version of Firefox has support for
WebDriver BiDi enabled, and the capability is
set to "true", it will be returned as part of
the "New Session" capabilities and contains
the host and port of the WebSocket server.
Differential Revision: https://phabricator.services.mozilla.com/D116689
Currently we have a `delete_session` function in
webdriver::server::Dispatcher which is called either when the session
has been cleanly deleted with a delete session method, or when we want
the session to be deleted. But all that method actually does is call
into WebDriverHander::delete_session, which then has to decide whether
to initiate a clean shutdown and then do any impl-specific shutdown
steps (close the connection in the case of geckodriver).
The whole setup is easier to understand if we make
webdriver::server::Dispatcher resposible for ensuring that the session
has been deleted by the time we notify the handler. We rename
`delete_session` `teardown_session` to reflect the fact that the
session may already have been deleted. This takes a single parameter,
a `SessionTeardownKind`, which indicates whether the session was
already deleted or not. In case there is a session, but it wasn't
deleted, `teardown_session` will attempt to send a `DeleteSession`
message.
On the handler side the `teardown_session` method which replaces
delete session gets a `SessionTeardownKind` that reflects whether we
ever handled a DeleteSession response, either from an explict user
request or from the implicit message sent by the dispatcher. In
geckodriver we use this to decide whether to wait for the browser to
close by itself before signalling it.
This fixes several issues; a regression in which we were waiting for
the browser to shut down when we shouldn't, and an issue where we were
sending too many delete session messages in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D116886
With Marionette being a part of Remote Agent now some
more code gets consolidated. As such the preferences
for logging will move soon to "webdriver.log.*". Also
"marionette.log.*", and "remote.log.*" will be removed.
This prepares geckodriver for the upcoming change on
bug 1700392.
Differential Revision: https://phabricator.services.mozilla.com/D116688
Currently the MarionetteHandler class owns some data like the browser
instance which conceptually should live as long as a specific session,
not for the whole lifetime of the handler (which is basically the
lifetime of the server). This is problematic because it means we need
to consider the possibility of accessing that data after the session
is complete.
MarionetteHandler and MarionetteConnetion are also written in a way
that exposes a partially constructed state (constructing an instance
returns an object with several optional fields that are filled in
later). This means we also need to consider the possibility of these
fields being None when in fact it would always be a bug to be in that
situation.
To fix both these issues, this patch refactors the code around the
Marionette connection. All state that lives for the length of the
connection/session is put onto the MarionetteConnection
object. MarionetteHandler itself contains only the static
configuration data from GeckoDriver startup, plus an optional
connection (it would be good to also refactor this so that once a
session was started the MarionetteHandler itself would change type,
such that it's statically verifyiable that we never call things that
require a session before the session is started or after it's closed,
but that would require more changes in the WebDriver library).
In addition, constructing the Connection instance now creates the
connection and fully populates the fields.
Handling of the different browser types (local owned by GeckoDriver,
remtoe owned by GeckoDriver, and local not owned by GeckoDriver) is
moved out into the Browser enum and variants instead of being
different methods in MarionetteHandler.
When closing a connection it's necessary to call the close() method on
the browser object to ensure that it's closed (if owned by
GeckoDriver) and all state is cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D112612
Previously we would just ignore the command-line provided profile,
write prefs to a new profile and then use the command line provided
one. That doesn't really make sense.
Now instead we try to write the prefs to the provided profile and
restore it after the test run.
Depends on D101771
Differential Revision: https://phabricator.services.mozilla.com/D101772
Previously we would just ignore the command-line provided profile,
write prefs to a new profile and then use the command line provided
one. That doesn't really make sense.
Now instead we try to write the prefs to the provided profile and
restore it after the test run.
Depends on D101771
Differential Revision: https://phabricator.services.mozilla.com/D101772
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Marionette enables itself only when --marionette is passed in. Given that
command line arguments can only be passed in using the debug configuration, it
is safe to send this event all the time.
Differential Revision: https://phabricator.services.mozilla.com/D113829
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Previously we would just ignore the command-line provided profile,
write prefs to a new profile and then use the command line provided
one. That doesn't really make sense.
Now instead we try to write the prefs to the provided profile and
restore it after the test run.
Depends on D101771
Differential Revision: https://phabricator.services.mozilla.com/D101772
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
