With bug 1680407 fixed I'm not able to start a Fenix Nightly build without a crash. But the WebDriver:NewSession command hangs and finally causes a connection drop after the socket timeout.

I assume that due to the displayed start page Marionette is not able to find the initial browser window and hangs in waitForWindow().

Note that this page is only displayed in Fenix Nightly, but not in Beta nor Release. So I assume it's related to that. Most likely it has another type than navigator:geckoview.

When I manually close the initial page, Marionette finds the window and the WebDriver:NewSession command succeeds.

Sebastian, is there a way to stop Fenix from loading this initial page? Maybe a preference?

Maybe instead of the plain Promise we should use a TimedPromise here and early return if the browser window cannot be found within 5s, which seems to be long enough.

Sebastian, can you please have a look at comment 0? Thanks.

So it's actually the welcome (onboarding) view that is blocking us here. And as it looks like there is no window open because Services.wm.getMostRecentWindow(null) returns null.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #0)

Sebastian, is there a way to stop Fenix from loading this initial page? Maybe a preference?

Not a Gecko preference, but an Android preference, which is saved in an XML file in the app directory. Would that help you? If yes, then I could lookup the exact file/keys.

(In reply to Sebastian Kaspari (:sebastian; :pocmo) from comment #4)

Sebastian, is there a way to stop Fenix from loading this initial page? Maybe a preference?

Not a Gecko preference, but an Android preference, which is saved in an XML file in the app directory. Would that help you? If yes, then I could lookup the exact file/keys.

Is that new for Fenix 88, or why is it only a problem with Nightly right now? Modifying that file is actually not something we would like to do. Could there be another option like an intent argument or an entry in the yml config file that would allow to skip that? Maybe some generic key with automation in its name that could be re-used for other automation related tweaks?

So we made a bit of progress here. With the help from Andrew we figured out that the default intents that we might want to use are the following:

"androidIntentArguments": [
    "-a",
    "android.intent.action.VIEW",
    "-d",
    "about:blank",
],

That opens Fenix with the about:blank page opened. The onboarding view is no longer displayed! So this is great.

What I wonder is if we as best should define a set of default intents to use for specific applications. By default we could support Firefox (Fenix) and geckoview_example. When a client wants to use a different view then all intent arguments have to be provided and they will completely override the default ones.

I have a better understanding of the problem now, thank you :whimboo.

Maybe this is not possible, but could we still launch and not block on waitForWindow()?

So that we could use geckodriver for other scenarios that don't involve a browser window.

Currently the Fenix MAIN tests do this -- they launch Fenix via geckodriver and then ignore the Marionette exception because Fenix is launched and that's all we need.

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #7)

Maybe this is not possible, but could we still launch and not block on waitForWindow()?

This is a different issue and actually a regression in Firefox 88. I filed bug 1700755 to get this fixed.

James, mind having a look at comment 6? Shall we ship geckodriver with a default set of intents / activities, or just have a good documentation? I would prefer the latter option, which makes us more flexible.

I'm not sure I understand why shipping a default set would make us less flexible? From a UX point of view I'd expect us to ship the intents required to make things work out of the box, but allow people to disable or modify them as required.

It makes us less flexible when those views / intents get changed. We might have to carry around backward compatible code for a while. But lets try.

Browsers to support are:

• Firefox (org.mozilla.firefox, org.mozilla.firefox_beta, org.mozilla.fenix, org.mozilla.fenix.debug)
• GeckoView_Example (org.mozilla.geckoview_example)
• RefBrowser (org.mozilla.reference.browser)

The activity that will work for all the browsers is: org.mozilla.fenix.IntentReceiverActivity. Only for geckoview_example the default activity (.GeckoViewActivity) has to be used.

Intents to use:

"androidIntentArguments": [
    "-a",
    "android.intent.action.VIEW",
    "-d",
    "about:blank",
]

Once it has been landed and geckodriver 0.30.0 released we need to update the firefoxOptions MDN page:

https://github.com/mdn/content/blob/main/files/en-us/web/webdriver/capabilities/firefoxoptions/index.html

Depends on D109870

Backed out for bustage on capabilities.rs

backout: https://hg.mozilla.org/integration/autoland/rev/098c3172afae38b129ae08e1586499f698a816f3

push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=ce2c38c1386c6caeea2b3c2622319702a42febd4&searchStr=build

failure logs:

• build

[task 2021-03-29T12:43:52.403Z] 12:43:52 INFO - Running CARGO=/builds/worker/fetches/rustc/bin/cargo CARGO_BIN_NAME=geckodriver CARGO_CRATE_NAME=geckodriver CARGO_MANIFEST_DIR=/builds/worker/checkouts/gecko/testing/geckodriver CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='Proxy for using WebDriver clients to interact with Gecko-based browsers.' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MPL-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=geckodriver CARGO_PKG_REPOSITORY='https://hg.mozilla.org/mozilla-central/file/tip/testing/geckodriver' CARGO_PKG_VERSION=0.29.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=29 CARGO_PKG_VERSION_PATCH=0 [..] zip=/builds/worker/workspace/obj-build/testing/geckodriver/./x86_64-unknown-linux-gnu/debug/deps/libzip-29f8a64abd13bf86.rlib -C opt-level=2 -C debuginfo=2 -C force-frame-pointers=yes -Dwarnings -C codegen-units=1
[task 2021-03-29T12:43:52.403Z] 12:43:52 ERROR - error[E0425]: cannot find value value in this scope
[task 2021-03-29T12:43:52.403Z] 12:43:52 INFO - --> testing/geckodriver/src/capabilities.rs:936:65
[task 2021-03-29T12:43:52.403Z] 12:43:52 INFO - |
[task 2021-03-29T12:43:52.403Z] 12:43:52 INFO - 936 | firefox_opts.insert("androidActivity".into(), json!(value));
[task 2021-03-29T12:43:52.404Z] 12:43:52 INFO - | ^^^^^ not found in this scope
[task 2021-03-29T12:43:52.404Z] 12:43:52 ERROR - error: aborting due to previous error

• Toolchain builds

[task 2021-03-29T12:49:32.121Z] Running rustc --crate-name geckodriver --edition=2018 testing/geckodriver/src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -C metadata=83a50d7495af3fb0 --out-dir /builds/worker/workspace/build/src/target/x86_64-pc-windows-msvc/release/deps --target x86_64-pc-windows-msvc -C linker=/builds/worker/fetches/clang/bin/lld-link [..] --extern zip=/builds/worker/workspace/build/src/target/x86_64-pc-windows-msvc/release/deps/libzip-24ca1c053397ac87.rlib -Ctarget-feature=+crt-static
[task 2021-03-29T12:49:32.703Z] error[E0382]: borrow of moved value: package
[task 2021-03-29T12:49:32.703Z] --> testing/geckodriver/src/capabilities.rs:610:27
[task 2021-03-29T12:49:32.703Z] |
[task 2021-03-29T12:49:32.703Z] 566 | let package = package_json
[task 2021-03-29T12:49:32.703Z] | ------- move occurs because package has type std::string::String, which does not implement the Copy trait
[task 2021-03-29T12:49:32.703Z] ...
[task 2021-03-29T12:49:32.703Z] 586 | let mut android = AndroidOptions::new(package, storage);
[task 2021-03-29T12:49:32.703Z] | ------- value moved here
[task 2021-03-29T12:49:32.703Z] ...
[task 2021-03-29T12:49:32.703Z] 610 | match package.as_str() {
[task 2021-03-29T12:49:32.703Z] | ^^^^^^^ value borrowed here after move
[task 2021-03-29T12:49:32.703Z]
[task 2021-03-29T12:49:32.828Z] error: aborting due to previous error

This was caused by a bad merge when there were conflicts. I just updated the patches.

https://hg.mozilla.org/mozilla-central/rev/c525d2b84c73
https://hg.mozilla.org/mozilla-central/rev/fc28879abbd0

Removing DDN as per discussion on https://github.com/mdn/content/issues/4315