User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

System Setup (Maybe important?):

• Recent Manjaro
• Wayland (swaywm)
• Firefox 83
• geckodriver 0.28.0 (c00d2b6acd3f 2020-11-03 16:29 +0200)
• about 10 windows with around 140 tabs open

1. Open firefox using "firefox --marionette" and make sure to set "MOZ_ENABLE_WAYLAND=1"
2. Use "geckodriver --connect-existing --marionette-port 2828" to start the geckodriver.
3. (From this on I used a rust binding (https://github.com/stevepryde/thirtyfour See also issue: https://github.com/stevepryde/thirtyfour/issues/34 ).

I assume steps from now on due to usage of that binding:

4. Create a session
5. Ask for window handles.

Actual results:

This is the error log using --log trace from geckodriver:

https://paste.ubuntu.com/p/thxdKRPDdB/

It returns Error 500 with "TypeError: browser.browsingContext is null" as a message.

Also when closing the tab selected when starting geckodriver it fails to find any window until it gets restarted. It seems to only see one tab.

Expected results:

It should have listed all tabs across all windows and workspaces.

Henrik, is this bug related to Fission (since this bug is related to browser.browsingContext)? Does it need to block shipping Fission MVP?

Marcel, do you see the same with Firefox 84 beta, or Firefox Nightly? I would appreciate if you could take a look at those. So far we aren't aware of that problem.

Also do you have other windows open that are not browser windows, like downloads, library?

Hi I will check the beta and nightly. Might take a day or so as it is like 22:00 on my side of the world :)

No other firefox or thunderbird windows are open.

Please note that Firefox 84 will be released tomorrow. As such make sure that you are checking 84 and 85. Thanks.

I can confirm it works with Firefox 84 with a single window open (and a single tab). I will try tomorrow with the same windows/tabs again. Just did not yet move my firefox 83 profile over which has all the history to open them up easily.

It also fails on firefox 84 as soon as I have multiple tabs and windows open (started the profile I used on the firefox 83 version).

Going to try firefox 85 as well

With firefox 85 the error message slightly improved but the error itself still happens

➜  ~ geckodriver --log trace --connect-existing --marionette-port 2828
1607985943442	geckodriver	INFO	Listening on 127.0.0.1:4444
1607985948880	webdriver::server	DEBUG	-> POST /session {"capabilities":{"firstMatch":[{}],"alwaysMatch":{"browserName":"firefox"}},"desiredCapabilities":{"browserName":"firefox"}}
1607985948881	geckodriver::marionette	DEBUG	Waiting 60s to connect to browser on 127.0.0.1:2828
1607985948898	geckodriver::marionette	DEBUG	Connection to Marionette established on 127.0.0.1:2828.
1607985948913	webdriver::server	DEBUG	<- 200 OK {"value":{"sessionId":"0def1768-4f41-4c12-8e25-49c517b8ffb8","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"85.0a1","moz:accessibilityChecks":false,"moz:buildID":"20201214091023","moz:geckodriverVersion":"0.28.0","moz:headless":false,"moz:processID":94213,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.9.11-3-MANJARO","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1607985948915	webdriver::server	DEBUG	-> POST /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/timeouts {"script":60000,"pageLoad":60000,"implicit":30000}
1607985948919	webdriver::server	DEBUG	<- 200 OK {"value":null}
1607985948920	webdriver::server	DEBUG	-> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/title
1607985948920	webdriver::server	DEBUG	<- 200 OK {"value":"Commits · Nucleon-eV/mitfahrbank-flutter"}
1607985948921	webdriver::server	DEBUG	-> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/window
1607985948922	webdriver::server	DEBUG	<- 200 OK {"value":"94"}
1607985948923	webdriver::server	DEBUG	-> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/window/handles
1607985948924	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: can't access property \"id\", browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1450:15\nget@chrome://marionette/content/driver.js:249:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1495:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}

Could you please check if it is a special window or tab, which triggers that? I cannot explain why that happens, and I cannot reproduce it locally on MacOS. If you can't check that I could provide a special build of Firefox that adds more logging to the get window handles method.

Oh, and that started with Firefox 83, and wasn't visible with 82?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away 12/07 - 12/11) from comment #8)

Could you please check if it is a special window or tab, which triggers that? I cannot explain why that happens, and I cannot reproduce it locally on MacOS. If you can't check that I could provide a special build of Firefox that adds more logging to the get window handles method.

A Special build would be nice as it are quite many tabs to check :/

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away 12/07 - 12/11) from comment #9)

Oh, and that started with Firefox 83, and wasn't visible with 82?

I did never have 82 on this system. So I dont know. to test I will check how to downgrade firefox on arch.

You can use https://github.com/mozilla/mozdownload to get older builds of Firefox from our servers. So no need for you to build yourself.

You can get mozdownload from https://pypi.org/project/mozdownload/.

One thing I am wondering about which started with firefox nightly is that the robot in the addressbar seems to only show in one of the windows (each on different workspaces in swaywm). Not sure if thats a seperate issue or contributed here or just a visual thing.

No, the robot should be present for all windows. And that is what I also cannot reproduce. Can you please provide some steps in how you get there? As best with a fresh profile. Did you download a nightly via mozdownload? Or where did you get it?

So the env itself is the same as before (wayland, swaywm, manjaro). The firefox nightly version is installed using https://aur.archlinux.org/packages/firefox-nightly/ . Each window is on another workspace and firefox-nightly is started using an exec inside of the sway config. Sway was started directly from the shell (no gdm or similiar).

Each window was opened with the firefox "autorestart" feature where it reopens the last open windows.

The exact command used is firefox-nightly -P default-release --marionette. The profile given was my firefox 83 profile.

Please ask if any further information is needed. I will later today test firefox 82 and test with a fresh profile

Some other things to check:

• Does the same happen when you don't use the arch linux builds but always ours as downloadable via mozdownload?
• What happens when all browser windows are on the same workspace?

Still didn't get around to test ff82 due to homework I do today but as it just crashed (error reported using the error report tool) I was able to check behavior if they are all on the same workspace:

The behavior seems to be the same. Automation only shows on the first windows address bar instead of all of them.
Not surprising but I tested anyway -> geckodriver still does the same error.

For crashes you can go to about:crashes and report them. Feel free to drop the URL here.

Otherwise thanks for the update and good to know that the workspaces aren't the problem. Let us know when you wre able to test older versions, so we might know if it is a regression.

The crash is https://crash-stats.mozilla.org/report/index/c647c1ba-5a92-4a91-807c-4ee180201217 . But I think it is unrelated to this.

(In reply to Chris Peterson [:cpeterson] from comment #1)

Henrik, is this bug related to Fission (since this bug is related to browser.browsingContext)? Does it need to block shipping Fission MVP?

(In reply to Marcel Radzio from comment #6)

It also fails on firefox 84 as soon as I have multiple tabs and windows open (started the profile I used on the firefox 83 version).

(In reply to Marcel Radzio from comment #7)

With firefox 85 the error message slightly improved but the error itself still happens

Since this bug is reproducible in Firefox 84 and 85, it's not a Fission bug (unless it's a regression from a Fission code change that is affecting non-Fission behavior).

Marcel, when you have some updates regarding your testing please let us know. Thanks.

No further response from reporter, and I cannot reproduce. I'm happy to reopen when the requested information has been provided.

Hi I am sorry for no response in a long time. I just didnt find any time to respond.

Also I in between had to reinstall my system and now am on Arch instead of Manjaro. On this new system it works flawless with firefox-nightly so I cannot reproduce my original bug sadly :/

Actually nvm I can still reproduce it. I can get the current url but not window handles:

Error: Standard(WebDriverError { error: UnknownError, message: "TypeError: can\'t access property \"id\", browser.browsingContext is null", stack: "", delete_session: false }}

Is returned when using firefox nightly, current geckodriver from master branch and https://github.com/jonhoo/fantoccini as rust client.

Geckodriver log is:

➜  ~ geckodriver --port 4444 --connect-existing  --marionette-port 2828 --log debug
1612360768093	geckodriver	INFO	Listening on 127.0.0.1:4444
1612360769661	webdriver::server	DEBUG	-> POST /session {"capabilities": {"alwaysMatch":{"goog:chromeOptions":{"w3c":true},"pageLoadStrategy":"normal"},"firstMatch":[{}]}}
1612360769662	geckodriver::marionette	DEBUG	Waiting 60s to connect to browser on 127.0.0.1:2828
1612360769662	geckodriver::marionette	DEBUG	Connection to Marionette established on 127.0.0.1:2828.
1612360769669	webdriver::server	DEBUG	<- 200 OK {"value":{"sessionId":"71f82dc4-0124-4e8f-9125-f26f706c5ecb","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"87.0a1","goog:chromeOptions":{"w3c":true},"moz:accessibilityChecks":false,"moz:buildID":"20210130194115","moz:geckodriverVersion":"0.29.0","moz:headless":false,"moz:processID":123959,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.10.11-arch1-1","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1612360769670	webdriver::server	DEBUG	-> GET /session/71f82dc4-0124-4e8f-9125-f26f706c5ecb/url 
1612360769677	webdriver::server	DEBUG	<- 200 OK {"value":"https://docs.rs/fantoccini/0.17.1/fantoccini/struct.Client.html#method.close"}
1612360769678	webdriver::server	DEBUG	-> GET /session/71f82dc4-0124-4e8f-9125-f26f706c5ecb/window/handles 
1612360769679	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"un
known error","message":"TypeError: can't access property \"id\", browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}

I will get back to testing now that I can reproduce it. I am using a minimal code for this: https://gist.github.com/MTRNord/443e2f3acce029fabd35b40da5d8b19d

The second call for windows is the one not working. the url always works. I will try to test the other requested things with that code

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

Some other things to check:

• What happens when all browser windows are on the same workspace?

This seems to not make any difference in behavior. The bug stays exactly the same.

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

Some other things to check:

• Does the same happen when you don't use the arch linux builds but always ours as downloadable via mozdownload?

Latest Beta from mozdownload: (86.0b5) and latest (85.0)

Error:

Error: Standard(WebDriverError { error: UnknownError, message: "TypeError: browser.browsingContext is null", stack: "", delete_session: false })

Logs from Geckodriver:

➜  ~ geckodriver --port 4444 --connect-existing  --marionette-port 2828 --log debug         1612361897323	geckodriver	INFO	Listening on 127.0.0.1:4444
1612361899373	webdriver::server	DEBUG-
> POST /session {"capabilities": {"alwaysMatch":{"goog:chromeOptions":{"w3c":true},"pageLoadStrategy":"normal"},"firstMatch":[{}]}}
1612361899373	geckodriver::marionette	DEBUGWaiting 60s to connect to browser on 127.0.0.1:2828
1612361899389	geckodriver::marionette	DEBUGConnection to Marionette established on 127.0.0.1:2828.
1612361899406	webdriver::server	DEBUG<- 200 OK {"value":{"sessionId":"344f2b21-8ada-4d48-9525-5de18e42cb1e","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"86.0","goog:chromeOptions":{"w3c":true},"moz:accessibilityChecks":false,"moz:buildID":"20210202185823","moz:geckodriverVersion":"0.29.0","moz:headless":false,"moz:processID":129181,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.10.11-arch1-1","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1612361899407	webdriver::server	DEBUG-> GET /session/344f2b21-8ada-4d48-9525-5de18e42cb1e/url 
1612361899411	webdriver::server	DEBUG<- 200 OK {"value":"https://de.wikipedia.org/wiki/Liste_mathematischer_Symbole"}
1612361899413	webdriver::server	DEBUG-> GET /session/344f2b21-8ada-4d48-9525-5de18e42cb1e/window/handles 
1612361899413	webdriver::server	DEBUG<- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}

Firefox ESR (78.7.0esr)

Works without any problems and returns expected results.

Note: Everything was tested with the same code and same profile

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

Oh, and that started with Firefox 83, and wasn't visible with 82?

I tried mozdownload 82.0b9 version too and it has the same error as I get with 86 and 85 I will go and try to step back until it works to pin point where it started

Ok I went back every version between 82 and 79.0b1 now. It seems that I get the error on all of them. It goes away on the esr version.

Thanks a lot for the details, and especially the regression check. Given that 78ESR is fine I had a look which changes went into the 79 release, and the only fix is from bug 1519335.

The change that caused it for you is:
https://hg.mozilla.org/integration/autoland/rev/db55b898e188#l2.103

So I assume that when this method gets called the content browser hasn't been created yet, and as such there is no browsing context available.

When you ignore the error and repeat the command does it eventually return the list of window handles, or is the failure permanent?

I will try that :) Going to let it run in a loop for some time and report back :)

I just noticed that sometimes the errors changes from:

windows: Err(
    Standard(
        WebDriverError {
            error: UnknownError,
            message: "TypeError: can\'t access property \"id\", browser.browsingContext is null",
            stack: "",
            delete_session: false,
        },
    ),
)

to

windows: Err(
    Standard(
        WebDriverError {
            error: UnknownError,
            message: "TypeError: can\'t access property \"id\" of null",
            stack: "",
            delete_session: false,
        },
    ),
)

It seems to happen a lot less than the first error.

Also not sure how often I should try but even after 1600 tries I had not once success. (Each time calling that endpoint in a loop)

Oh and not sure if It matters but between each try I slept 1s.

Log at geckodriver from that other error is:

1612387138155	webdriver::server	DEBUG	-> GET /session/136b0885-5c5f-4b99-90fc-026200acb26b/window/handles 
1612387138155	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: can't access property \"id\" of null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}

Wow, ok. So this is really, really puzzling. We have never seen such a problem in our own CI or locally when running any test.

So I was actually wrong above. getIdForBrowser() clearly gets the content browser, and returns early if it's null. In case it exists we then check if a content browser is already registered via its permanentKey. But that's also not the case here given that we always fail to add the content browser to the cache:

https://searchfox.org/mozilla-central/rev/927e525f481a93a8f63d27a78ae6201e42b1b1fb/testing/marionette/driver.js#1455-1465

Could you please do me a favor and test the following: When the call to get handles fails please suspend the test and manually open the browser toolbox (see web developer menu). It will allow you to interact with the chrome code of Firefox. There please open the web console and execute the following code: gBrowser.selectedBrowser.browsingContext. Does that return a valid browsing context?

Web console is the one that is in every tab correct?

In that case I do get:

Uncaught ReferenceError: gBrowser is not defined
    <anonymous> debugger eval code:1

Though I am not 100% sure if I am in the correct js console :)

I get this error in any tab

No, I don't mean the web console. It looks like you will have to enable devtools.chrome.enabled first in about:config before you will see this menu item.

Whatever is broken here I'm sure that bug 1680479 should get rid of this problem.

Whoops I missunderstood the editor apparently. Lets try this again:

Result:

CanonicalBrowsingContext { currentWindowGlobal: WindowGlobalParent, topChromeWindow: ChromeWindow chrome://browser/content/browser.xhtml, currentRemoteType: "webIsolated=https://mozilla.org", embedderWindowGlobal: WindowGlobalParent, secureBrowserUI: XPCWrappedNative_NoHelper, webProgress: XPCWrappedNative_NoHelper, sessionHistory: XPCWrappedNative_NoHelper, mediaController: MediaController, name: "", parent: null }

Or as the enlarged version: https://matrix.nordgedanken.dev/_matrix/media/r0/download/nordgedanken.dev/c5f0e98dbe998b2555b85d201af7d6e1700e5a29 (screenshot)

It looks like that I can reproduce the failure on my own now when executing the following code in the browser console:

var hs = [];

for (let win of Services.wm.getEnumerator(null)) {
  let tabBrowser = win.gBrowser;

  // Only return handles for browser windows
  if (tabBrowser && tabBrowser.tabs) {
    for (let tab of tabBrowser.tabs) {
      console.log(tab);
      let winId = tab.linkedBrowser.browsingContext.id;
      if (winId !== null) {
        hs.push(winId);
      }
    }
  }
}

console.log(hs);

It's basically the code that Marionette uses to get all the window handles. I will have a look.

So the problem is indeed related to some tabs that aren't loaded yet, and as such don't have an active browser. This can happen when you have a number of tabs open, and restart Firefox. After the restart only the current tab and all pinned tabs are loaded. Running the code above will cause failures for each of the not yet loaded tabs.

Marcel, when Firefox gets opened by your test how many tabs are open? Usually it should be a single one, but maybe you make use of a custom profile that has some not yet loaded background tabs?

Yeah I run my usual profile for this. So I have easily over 60 open tabs in this.

I attach geckodriver to my regular already open driver instead of opening a new browser as the goal was to automate parts of my usual browser usage and bind it to some hardware buttons :)

I am however wondering why it worked in the esr version or did that behavior change later on?

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

So the problem is indeed related to some tabs that aren't loaded yet, and as such don't have an active browser. This can happen when you have a number of tabs open, and restart Firefox. After the restart only the current tab and all pinned tabs are loaded. Running the code above will cause failures for each of the not yet loaded tabs.

Indeed after I went ahead and loaded every tab it works.

Yes, see my comment 28. Moving away from outerWindowID, which seems to be always present even with a tab unloaded, it doesn't work with the browsingContext that only exists for a valid browser.

Note that we strongly advice not to use your normal Firefox profile for automation tasks, and especially not even connecting to a running instance. There are various side-effects (like navigator.webdriver always be true), and Firefox accepting commands from external tools via the open socket by Marionette.

So we indeed can get this fixed by bug 1680479 and would have to account for unloaded tabs.

Thanks for all your help.

Thanks for the help debugging it! And I am aware of the side effects :)

With bug 1680479 fixed this is issue is also fixed now. To ensure we do not regress it in the future I'm going to add some unit tests.

https://hg.mozilla.org/mozilla-central/rev/8f0acc0b26ce