1682062 - "TypeError: browser.browsingContext is null" for WebDriver:GetWindowHandles when unloaded tabs are present

Status: RESOLVED FIXED

(Remote Protocol :: Marionette, defect, P3)

Description

[Marcel Radzio]

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.

Comment 1

[Chris Peterson [:cpeterson]]

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

Comment 2

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

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?

Comment 3

[Marcel Radzio]

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.

Comment 4

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

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

Comment 5

[Marcel Radzio]

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.

Comment 6

[Marcel Radzio]

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

Comment 7

[Marcel Radzio]

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"}}

Comment 8

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

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.

Comment 9

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

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

Comment 10

[Marcel Radzio]

(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.

Comment 11

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

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/.

Comment 12

[Marcel Radzio]

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.

Comment 13

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

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?

Comment 14

[Marcel Radzio]

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

Comment 15

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

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?

Comment 16

[Marcel Radzio]

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.

Comment 17

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

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.

Comment 18

[Marcel Radzio]

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

Comment 19

[Chris Peterson [:cpeterson]]

(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).

Comment 20

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

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

Comment 21

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

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

Comment 22

[Marcel Radzio]

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 :/

Comment 23

[Marcel Radzio]

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

Comment 24

[Marcel Radzio]

(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.

Comment 25

[Marcel Radzio]

(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

Comment 26

[Marcel Radzio]

(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

Comment 27

[Marcel Radzio]

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.

Comment 28

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

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?

Comment 29

[Marcel Radzio]

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

Comment 30

[Marcel Radzio]

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)

Comment 31

[Marcel Radzio]

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

Comment 32

[Marcel Radzio]

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"}}

Comment 33

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

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?

Comment 34

[Marcel Radzio]

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 :)

Comment 35

[Marcel Radzio]

I get this error in any tab

Comment 36

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

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.

Comment 37

[Marcel Radzio]

Attachment: Resut of gBrowser.selectedBrowser.browsingContext

Hi that returned:

```

```

Comment 38

[Marcel Radzio]

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)

Comment 39

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

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.

Comment 40

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

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?

Comment 41

[Marcel Radzio]

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?

Comment 42

[Marcel Radzio]

(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.

Comment 43

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

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.

Comment 44

[Marcel Radzio]

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

Comment 45

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

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.

Comment 46

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

Attachment: Bug 1682062 - [marionette] Added Marionette unit tests for unloaded tab behavior.

Comment 47

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8f0acc0b26ce
[marionette] Added Marionette unit tests for unloaded tab behavior. r=marionette-reviewers,jdescottes

Comment 48

[Alexandru Michis [:malexandru]]

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