This was initially supposed to be handled in Bug 1533058, but for now we will keep using BrowserOpenTab to open tabs on Firefox desktop in marionette/browser.sys.mjs openTab.

We should consistently use TabManager.addTab to create tabs in the remote codebase, but doing so seems to make some tests intermittently fail.

We should also use the occasion to review which API should be used behing the scenes to open the tab. Right now TabManager.addTab uses tabBrowser.addTab, but maybe we should rely on window.BrowserOpenTab

By using BrowserOpenTab() to open a new tab in Firefox there is also the browser-open-newtab-start notification that gets send out for performance tracking. If we stop using this method and instead use gBrowser.addTab() we would loose that (or if needed would have to send it out ourselves?).

Gijs, do you think that this notification could be important for some parts in Firefox or tests? By default we turn off Telemetry anyway in Marionette so maybe its irrelevant?

If we are going with gBrowser.addTab() we might have to wait for the Ubuntu 22.04 upgrade of test machines (bug 1725245) because using this API causes test failures with focus on Linux machines in CI only.

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

By using BrowserOpenTab() to open a new tab in Firefox there is also the browser-open-newtab-start notification that gets send out for performance tracking. If we stop using this method and instead use gBrowser.addTab() we would loose that (or if needed would have to send it out ourselves?).

Gijs, do you think that this notification could be important for some parts in Firefox or tests? By default we turn off Telemetry anyway in Marionette so maybe its irrelevant?

Yeah, I don't think the notification is relevant.

If we are going with gBrowser.addTab() we might have to wait for the Ubuntu 22.04 upgrade of test machines (bug 1725245) because using this API causes test failures with focus on Linux machines in CI only.

Do we know why? This smells like a race condition of some kind in marionette. The whole thing doesn't make much sense because BrowserOpenTab still ends up calling addTab at some point down the line. So presumably the only difference between the case where we lose the race and where we win the race is a parameter of some kind? I guess bug 1533058 comment 38 asked the same question.

From looking at that discussion and the issues that only reproduce on infra, I can't quite figure out whether there was analysis done in terms of what the difference for the two calls to addTab ends up being? That seems like the most straightforward way to resolve the potential difference so you end up with an identical call to addTab... you can just use local logging - you don't need to reproduce any failures on infra.

I guess if this switches to gBrowser.addTab we can revert the change in bug 1533058 to allow overriding the url for BrowserOpenTab...

(In reply to :Gijs (he/him) from comment #2)

Gijs, do you think that this notification could be important for some parts in Firefox or tests? By default we turn off Telemetry anyway in Marionette so maybe its irrelevant?

Yeah, I don't think the notification is relevant.

Thanks. That gives me confidence.

Do we know why? This smells like a race condition of some kind in marionette. The whole thing doesn't make much sense because BrowserOpenTab still ends up calling addTab at some point down the line. So presumably the only difference between the case where we lose the race and where we win the race is a parameter of some kind? I guess bug 1533058 comment 38 asked the same question.

Sadly not given that any additional logging that I was using on try was not helpful yet to figure out the issue. Also interactive tasks were broken since the infra moved to GCP. With bug 1786307 fixed yesterday I'm finally able to use interactive tasks again. I might have the time to start looking at this bug by next week. It's not a priority for now so it might take a bit.

From looking at that discussion and the issues that only reproduce on infra, I can't quite figure out whether there was analysis done in terms of what the difference for the two calls to addTab ends up being? That seems like the most straightforward way to resolve the potential difference so you end up with an identical call to addTab... you can just use local logging - you don't need to reproduce any failures on infra.

I would like to see the real effect of behavior in CI when I make changes to the code. That would make it faster in discovering at which layer on top of gBrowser.addTab() the broken behavior gets introduced. Once found me can use several MOZ_LOG features (like focus, focus manager, widget) to check the differences of focus handling.

I guess if this switches to gBrowser.addTab we can revert the change in bug 1533058 to allow overriding the url for BrowserOpenTab...

Yes, absolutely!

Maybe my patch on bug 1798655 might have helped here. As we noticed BrowerOpenTab() doesn't actually focus the tab's content but sets the focus to the chrome window. If code in content then tries to focus an element it will take longer and you cannot assume that it's focused when the call to focus() returns. As such we explicitly set the focus to the linkedBrowser now when switching between tabs.

I pushed a try build to check if it works now with the focus fix included:
https://treeherder.mozilla.org/jobs?repo=try&revision=2e10b64d972b1d927281572467d15fe248457620

As the try build shows the issue with scrolling an element into view is still remaining on Linux shippable builds. As such we will pick-up this bug again when there is a bit more time or maybe when we got new Linux workers with a more up-to-date Ubuntu release.

I've pushed another try build to check if that may work nowadays:
https://treeherder.mozilla.org/jobs?repo=try&revision=ffa70322e87f35b5dab5c048ef4645b067e47a68

As it looks like all the tests are passing now. I would consider finishing the patch and get it landed again.

Actually quite a lot of tests are failing now because Element Click commands do not really trigger a click event. As such especially for Wd spec tests the no_browsing_context (no frame) tests fail because the frame doesn't get removed within 500ms when clicking the remove frame link. I cannot make up a connection between this behavior and using gBrowser.addTab().

Given that I don't have the time for further checks right now we may have to indeed wait until the new Wayland Linux machines are used for both Marionette and Wdspec.

Out of curiosity I just pushed the same set of tests for the Wayland test machines (via --full) to see if it makes a difference:
https://treeherder.mozilla.org/jobs?repo=try&revision=e981e079467637d019b63b27c942114f8da4a993

So the new Wayland workers show the exact same problem. As such we have to find a way to get this working in a different way.

I'm currently not working on this bug.

It looks like that this code change seems to work now after updating to newer Linux releases. Here a try build:
https://treeherder.mozilla.org/jobs?repo=try&revision=a603cb0833d5a47cde09ea9b4e3703a284e5ed3e

Tests are still failing and I can now as well reproduce locally with an up-to-date Ubuntu 24.04 release. The issue is not only that some elements cannot be scrolled into view, but also with finding elements on a page after navigation. As it looks like it takes about 1s until the element is actually retrievable by find_element(). Maybe that is related to the 1s throttle timer that pauses JS execution in background tabs. If that's the case it means that we do not correctly set the focus to the tab we want to switch to.

Note that this issue is only reproducible when I start the test and bring the Terminal window to front. As such it could also be an issue with the Focus manager. I'll dig in.

This is a very interesting case! We are opening a new tab in the background, and then switching to it to bring it to the foreground. The problem here is that when Firefox is in the background the visibilityState of the tab's document is showing visible all the time but doesn't allow us to retrieve the wanted element from the page. But then after about 1s it has the state hidden and the element can be retrieved:

1758876234499	Marionette	DEBUG	6 -> [0,40,"WebDriver:Navigate",{"url":"http://127.0.0.1:46209/clicks.html"}]
1758876234502	Marionette	TRACE	[18] Received event beforeunload for about:blank
1758876234505	Marionette	TRACE	Remoteness change detected. Set new top-level browsing context to 19
1758876234513	Marionette	TRACE	[19] Received event beforeunload for about:blank
1758876234517	Marionette	TRACE	[19] Received event pagehide for about:blank
1758876234538	Marionette	TRACE	[19] Received event DOMContentLoaded for http://127.0.0.1:46209/clicks.html
1758876234550	Marionette	TRACE	[19] Received event pageshow for http://127.0.0.1:46209/clicks.html
1758876234551	Marionette	DEBUG	6 <- [1,40,null,{"value":null}]
1758876234554	Marionette	DEBUG	6 -> [0,41,"WebDriver:FindElement",{"value":"333333","using":"link text"}]
1758876234561	RemoteAgent	TRACE	WebDriverProcessData actor created for PID 66930
1758876234565	Marionette	TRACE	[19] MarionetteCommands actor created for window id 34359738369

 **** bc: 19 ****
1758876234632	Marionette	DEBUG	6 <- [1,41,{"error":"no such element","message":"Unable to locate element: 333333","stacktrace":"RemoteError@chrome://remote/content/shared/RemoteError.sys.mjs:8:8\nWebDriverError@chrome://remote/content/shared/webdriver/Er ... chrome://remote/content/shared/webdriver/Errors.sys.mjs:555:5\ndom.find/</<@chrome://remote/content/shared/DOM.sys.mjs:136:16\n"},null]
1758876234633	Marionette	DEBUG	6 -> [0,42,"WebDriver:ExecuteScript",{"script":"return document.visibilityState;","args":[],"newSandbox":true,"sandbox":"default","line":508,"filename":"testing/marionette/harness/marionette_harness/tests/unit/test_click.py"}]

 **** bc: 19 ****
1758876234638	Marionette	DEBUG	6 <- [1,42,null,{"value":"visible"}]

[..]

1758876235692	Marionette	DEBUG	6 -> [0,80,"WebDriver:ExecuteScript",{"script":"return document.visibilityState;","args":[],"newSandbox":true,"sandbox":"default","line":508,"filename":"testing/marionette/harness/marionette_harness/tests/unit/test_click.py"}]

 **** bc: 19 ****
1758876235694	Marionette	DEBUG	6 <- [1,80,null,{"value":"hidden"}]
1758876235694	Marionette	DEBUG	6 -> [0,81,"WebDriver:FindElement",{"value":"333333","using":"link text"}]

 **** bc: 19 ****
1758876235707	Marionette	DEBUG	6 <- [1,81,null,{"value":{"element-6066-11e4-a52e-4f735466cecf":"58abe1ea-e911-4953-b5ff-a5d037fcc5c4"}}]
** duration: 1.155827522277832

Why is the document of the tab in focus now hidden? It feels like that the focus manager has an issue or we interact with the wrong document?

This failure is easy to reproduce on Ubuntu 24.04:

1. Apply the patch as attached to this bug
   1.1. Optionally disable all tests except one (test_click_link_page_load) in that file by changing test_ to tst_.
2. Run Marionette tests with mach marionette-test --gecko-log=- -vv testing/marionette/harness/marionette_harness/tests/unit/test_click.py
3. When Firefox opened move its window to the background
4. Observe the failure

Here I have a recorded Gecko profile for a working case, which comes first, and afterward the failing case:

https://share.firefox.dev/4nQhNrM

It's interesting that nothing (as per recorded screenshots) is actually updated in the browser when it fails. The test page was loaded thought, but no rendering is happening until something kicks in 0.8s later?

Emilio, not sure if that is an area you have expertise in and maybe could give a hint what might go wrong?

Sorry, I need some more context. So this is a test that navigates a tab and clicks a link?

When Firefox opened move its window to the background

like, totally covered? Or something else? Hidden tabs get throttled, and that includes foreground tabs in hidden windows...

It seems this could call window.focus() to raise window to the front?

(In reply to Emilio Cobos Álvarez [:emilio] from comment #19)

When Firefox opened move its window to the background

like, totally covered? Or something else? Hidden tabs get throttled, and that includes foreground tabs in hidden windows...

Oh yes, that's indeed the case. When the Terminal hides the complete Firefox window I can see the problem. If it's only covering parts it's working fine. Is there a way to disable throttling when the window is in the background?

It seems this could call window.focus() to raise window to the front?

No, this doesn't help.

We also do not have the problem when we make use of:

this.window.BrowserCommands.openTab({ url: "about:blank" });

But only with :

const tab = await gBrowser.addTab("about:blank",

see tabbrowser.js, and that also only on Linux but not on any other platform.

I think the same should happen on windows FWIW. But the other thing that is supposed to prevent this is this pref, doesn't it do the trick?

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

like, totally covered? Or something else? Hidden tabs get throttled, and that includes foreground tabs in hidden windows...

Oh yes, that's indeed the case. When the Terminal hides the complete Firefox window I can see the problem. If it's only covering parts it's working fine. Is there a way to disable throttling when the window is in the background?

Given that BrowserCommands.openTab() also ends-up finally calling gBrowser.addTab() I compared the parameter values and found that the focusUrlBar parameter needs to true to get it no longer failing. This parameter is handled at:

https://searchfox.org/firefox-main/rev/fd531836ca5e48e18a5afc171418bcbcb9d268e2/browser/components/tabbrowser/content/tabbrowser.js#1665-1707

Maybe there is a bug somewhere in this code related to the focus. But given that we used true before let me continue with this for now.

(In reply to Emilio Cobos Álvarez [:emilio] from comment #21)

I think the same should happen on windows FWIW. But the other thing that is supposed to prevent this is this pref, doesn't it do the trick?

No, this preference doesn't work as well. It's really the focusUrlBar parameter which makes it work for me on my Linux machine.

I'll use the focusUrlBar workaround for now and filed bug 1991149 to get the underlying issue investigated.

Backed out for causing multiple wpt failures.

• Backout link
• Push with failures
• Failure Log @table-fixed-minmax.html
• Failure Log @caretPositionFromPoint.html
• Failure Log @elementFromPoint-001.html

It's not clear what's going on. I pushed a try build with trace logs enabled:
https://treeherder.mozilla.org/jobs?repo=try&revision=a39b75d2525ec08715274b690d31b65be00cb0c1

I just noticed that there is another API that could be used to open new tabs and windows. It's called getContentWindowOrOpenURI():
https://searchfox.org/firefox-main/rev/7496c8515212669451d7e775a00c2be07da38ca5/browser/modules/BrowserDOMWindow.sys.mjs#361-364

It would be worth a try to check if switching to that method might help us here and get rid of the failures on Linux.

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

I just noticed that there is another API that could be used to open new tabs and windows. It's called getContentWindowOrOpenURI():
https://searchfox.org/firefox-main/rev/7496c8515212669451d7e775a00c2be07da38ca5/browser/modules/BrowserDOMWindow.sys.mjs#361-364

It would be worth a try to check if switching to that method might help us here and get rid of the failures on Linux.

That just ends up calling addTab as well: https://searchfox.org/firefox-main/rev/7496c8515212669451d7e775a00c2be07da38ca5/browser/modules/BrowserDOMWindow.sys.mjs#158,164

Perhaps an rr / pernosco trace of a failing/passing run would help here?

Thank you for that information Gijs! That saves me time for investigating. Also having such a situation in Pernosco is a good idea. I pushed a try build and will re-trigger individual jobs to get one failing:

https://treeherder.mozilla.org/jobs?repo=try&revision=3f1280fac577d3fc75794eb23729685cdb853786

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

https://treeherder.mozilla.org/jobs?repo=try&revision=3f1280fac577d3fc75794eb23729685cdb853786

Hm, I cannot find anything in these failing tests for wpt that references Pernosco. Could it be that web-platform tests do not support Pernosco yet?

The option looks to be there for me?