Clicking links from an extension page fails in some cases as of Firefox Beta 82.0

[ghostwords]

This worked as of Mozilla Firefox 81.0b9 and started failing after Beta switched to 82.0b1

System

• Version: geckodriver 0.27.0 (7b8c4f32cdde 2020-07-28 18:16 +0000)
• Platform: Linux
• Firefox: 82.0b2 (Beta and Nightly are failing)
• Selenium: Python bindings 3.141.0

Testcase

Something about clicking elements in extension windows that open new tabs/windows broke as of Firefox Beta 82. This worked in Firefox Beta 81.

In Beta 81 clicking elements in a moz-extension window would successfully open new (https/moz-extension) windows.

In Beta 82 no such windows are opened.

Pausing a test and then manually clicking the element succeeds in opening the window.

Trace-level log

Here are logs for a run of one of these newly failing tests:

Firefox Beta 82: geckodriver-bad.log
Firefox 80: geckodriver-good.log

[whimboo]

@ghostwords mind sharing the source of the test that's failing here? Also can you please check if latest Firefox Nightly works for you? I recently landed a fix for WebDriver:ElementClick which hasn't been uplifted to 82 yet.

[ghostwords]

The tests are still failing on the latest Nightly, unfortunately.

These are the test cases that fail: EFForg/privacybadger@b55e32b

Here is some documentation for running our test suite:
https://github.com/EFForg/privacybadger/blob/master/doc/tests.md#functional-tests

I'm hoping you'll know what might have changed inbetween 81 and 82 that would cause this issue without us having to come up with a minimum code reproduction.

Again, not all clicks are failing, only some clicks, ones that open new windows. The ones that fail, do so consistently.

[ghostwords]

I don't understand why this test succeeds in opening an extension page from an extension page, while this test fails.

[whimboo]

Thanks for all the details! I'm able to replicate the failure and will have a look what's causing it.

Note that in the documentation the dependency on xvfbwrapper is not mentioned the tests actually depend on even I don't want to run with xvfb.

[whimboo]

@ghostwords I have problems finding the geckodriver.log file in the current working directory. How do I get this created?

[whimboo]

Got it... Removing service_log_path=os.path.devnull from the pbtest.py helped.

[whimboo]

So I used mozregression (modified pbtest.py to use MOZREGRESSION_BINARY instead of BROWSER) to find the causing changeset:

mozregression --good 81 --bad 82 --command "pytest -v tests/selenium/popup_test.py"
[..]
 5:51.45 INFO: Test command result: 1 (build is bad)
 5:51.45 INFO: Narrowed integration regression window from [24b91757, eed643ef] (5 builds) to [24b91757, 4951412c] (2 builds) (~1 steps left)
 5:51.45 INFO: No more integration revisions, bisection finished.
 5:51.45 INFO: Last good revision: 24b917577203190f0e1c0b21f6ffaf4d07f1e8f6
 5:51.45 INFO: First bad revision: 4951412ca28ee33b50f4f8af722d01703feb7099
 5:51.45 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=24b917577203190f0e1c0b21f6ffaf4d07f1e8f6&tochange=4951412ca28ee33b50f4f8af722d01703feb7099

So it's the move of the navigation commands to the parent process (https://bugzilla.mozilla.org/show_bug.cgi?id=1612831). I will get a bug filed once I know what exactly is wrong now.

[whimboo]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1667377 for that case. Really strange that no internal and webdriver test caught that regression. It's a very important one. So thanks a lot for reporting it and all the details!

[ruescar]

@whimboo I also experienced a similar behaviour from Firefox 82+. A test clicking on an element to open a page in a new tab (<a target="_blank">link</>), would fail to open that page. However if you remove the target, then clicking does open a new page in the current context successfully.

[whimboo]

Yes, that's exactly the same problem. If you are eager you can test a try build that is currently running. The builds should be ready soon. Just open Treeherder and click artifacts in the lower pane. There is a tar.gz, .zip, or .dmg to download. Feel free to report back.

[ghostwords]

I'm glad my report was helpful and you found the issue! Thanks for Privacy Badger tests feedback; I'll update our documentation next week.

[ruescar]

Yes, that's exactly the same problem. If you are eager you can test a try build that is currently running. The builds should be ready soon. Just open Treeherder and click artifacts in the lower pane. There is a tar.gz, .zip, or .dmg to download. Feel free to report back.

@whimboo Could you be a bit more specific about which tar.gz contains the executable? There's several ones. I would like to try for both Linux and OSX

[whimboo]

You can grab the latest Nightly build that already contains that fix.

[ruescar]

@whimboo I just tried that latest Firefox NightlyDebug 83.0a1 on OSX and I confirm that the fix worked.

[whimboo]

That's good to hear! I just have requested the uplift of the patch for Firefox 82. So maybe already the next beta release will be shipped with the patch included. Thanks again for reporting the regression!

[ruescar]

I just tested 82.0~b4+build1-0ubuntu0.18.04.1 for Ubuntu Bionic, but on this build the fix doesn't seem to work.

[whimboo]

As I said, the uplift has been requested but hasn't been done yet. As such no beta release includes the patch yet. You can follow the referenced bug for updates. The earliest beta release would be beta5 but I would expect more beta6.

[whimboo]

FYI Firefox 82.0b6 will contain this fix.

[ruescar]

I confirm that I tested the fix successfully in 82.0~b6+build1-0ubuntu0.18.04.1 (Ubuntu Bionic). Thanks!