1699065 - Running Fenix "WebDriver:NewSession" causes TypeError: can't access property "tab", this.curBrowser is null

Status: RESOLVED INVALID

(Remote Protocol :: Marionette, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Originally filed as: https://github.com/mozilla/geckodriver/issues/1858

Running Selenium tests via geckodriver for Firefox on Android (Fenix) cause a type error in WebDriver:NewSession where this.curBrowser is null. Here the details:

1615970263741	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: can't access property \"tab\", this.curBrowser is null","stacktrace":"GeckoDriver.prototype.newSession@chrome://marionette/content/driver.js:681:7\ndespatch@chrome://marionette/content/server.js:295:40\nexecute@chrome://marionette/content/server.js:265:16\nonPacket/<@chrome://marionette/content/server.js:238:20\nonPacket@chrome://marionette/content/server.js:239:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}

The related code in driver.js is here:

https://searchfox.org/mozilla-central/rev/1a47a74bd5ba89f2474aa27c40bd478e853f3276/testing/marionette/driver.js#676

Basically curBrowser should be set by addBrowser when there is an existent window within waitForWindow.

But something seems to get wrong in this code:

https://searchfox.org/mozilla-central/rev/1a47a74bd5ba89f2474aa27c40bd478e853f3276/testing/marionette/driver.js#405-408

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is actually not per se a regression but rather an improvement to the situation that we had before. Up to the Firefox 84 release Marionette didn't initialize at all. Even not with the remote debugger preference (bug 1698968) set. That behavior can be forced by setting the marionette.actors.enabled preference to false up to Firefox 86. As such I assume that some framescript related code was busted in that browser version. But that's gone now in Firefox 87 (bug 1669172).

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Debug logging for Bug 1699065.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Andrew, given that you have a working Fenix setup locally, would you have the time to help us getting the attached patch into a Fenix Nightly build? I would like to know why exactly this failure happens and with the debug output we should hopefully get an idea.

I already pushed the patch to try so that we can get builds on Android:
https://treeherder.mozilla.org/jobs?repo=try&revision=6b803799c8627fb523deb246b242ae21f4a3431e

Thanks a lot!

Comment 4

[Andrew Creskey [:acreskey]]

Henrik, I've built a Fenix nightly, arm64, that uses the geckview from your push.
https://drive.google.com/file/d/1t3vpVuARhJZcHi91wORS06wV3XWlC40E/view?usp=sharing

(Verified via about:buildconfig).

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Andrew. Sadly I cannot run this build because it crashes a moment after startup. I had a conversation with Agi yesterday and as it looks like there seems to be a bug in Fenix around profile locking. He will have a look at this today.

Also I got some hints in how to build Fenix locally with a custom mozilla-central repository. So I will try this out today, and that might indeed be faster.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This failure might actually happen because the wrong activity of Fenix is used. With bug 1700290 we will add a default set of activities and intents for various GeckoView based browsers. so hopefully that will fix this bug.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This will indeed be fixed by bug 1700290. Using an activity that is not able to support automation simply won't work. So we always have to make sure that the correct activity is selected by default for known apps.

As such marking this bug as invalid.