Repeated hover does't work

[lnsight]

System

• Version: 0.24.0
• Platform: Ubuntu 18.04.2 LTS
• Firefox: 65.0.1-67.0a1
• Selenium: 3.141.0

Testcase

I found this bug in capybara test:

find_link('Label').hover # successful
<going to other page>
<going back>
find_link('Label').hover # does nothing (without any errors)

This case reproduced in https://gist.github.com/lnsight/1440b63dd3fbbaf4c612a0714342f66b

Stacktrace

Trace-level log

https://gist.github.com/lnsight/4dfcce03fe3c700a8f146d2570409338

[whimboo]

Could you please attach a trace-level log from geckodriver? Read more about reporting actionable bugs in our contribution guidelines.

[lnsight]

Trace-level log has been attached.

[whimboo]

There are tons of execute script calls in that log. Please create a minimized testcase best without any JS framework, or Javascript involved which still reproduces this problem. A trace log from such an execution would be good to have.

[twalpole]

@whimboo The JS is the Selenium isDisplayed JS atom, there are no other JS libraries required, it can basically be ignored for the purpose of that trace log.

[acikojevic]

I can confirm this issues exists in version 0.24.0

• Version: 0.24.0

• Platform: Windows 10

• Firefox: 65.0.1 (x64)

• Selenium: 3.13.0

Here is trace log for working hover action (first one):

1550669270948   webdriver::server       DEBUG   -> POST /session/e6683c10-61c0-460a-8af9-c5358dda9358/elements {
  "value": ".collection-table-row",
  "using": "css selector"
}
1550669270950   Marionette      DEBUG   0 -> [0,76,"WebDriver:FindElements",{"using":"css selector","value":".collection-table-row"}]
1550669270966   Marionette      DEBUG   0 <- [1,76,null,[{"element-6066-11e4-a52e-4f735466cecf":"b645c976-4ea1-4331-83d8-61c23ec1d5af"},{"element-6066-11e4-a52e-4f735466c ... ecf":"8cfecfe9-d4e8-4ca7-8c42-767a875f453f"},{"element-6066-11e4-a52e-4f735466cecf":"9a30adac-5b61-4126-8717-b15096e203fd"}]]
1550669270967   webdriver::server       DEBUG   <- 200 OK {"value":[{"element-6066-11e4-a52e-4f735466cecf":"b645c976-4ea1-4331-83d8-61c23ec1d5af"},{"element-6066-11e4-a52e-4f735466cecf":"01d2700d-e871-42b7-bd94-f183fabdfc8e"},{"element-6066-11e4-a52e-4f735466cecf":"0bb5553f-ea8a-49e9-b5dc-81713624f187"},{"element-6066-11e4-a52e-4f735466cecf":"72179192-0c6a-400e-9c9f-7168b5f663ff"},{"element-6066-11e4-a52e-4f735466cecf":"89ef2348-4cf8-4a13-8405-48ac1979f34d"},{"element-6066-11e4-a52e-4f735466cecf":"386ef913-4e55-4190-ae83-5e72b1801d40"},{"element-6066-11e4-a52e-4f735466cecf":"6b8606cc-0227-4c17-a497-db807bd42b57"},{"element-6066-11e4-a52e-4f735466cecf":"8cfecfe9-d4e8-4ca7-8c42-767a875f453f"},{"element-6066-11e4-a52e-4f735466cecf":"9a30adac-5b61-4126-8717-b15096e203fd"}]}
1550669271016   webdriver::server       DEBUG   -> POST /session/e6683c10-61c0-460a-8af9-c5358dda9358/actions {
  "actions": [
    {
      "id": "default mouse",
      "type": "pointer",
      "parameters": {
        "pointerType": "mouse"
      },
      "actions": [
        {
          "duration": 100,
          "x": 0,
          "y": 0,
          "type": "pointerMove",
          "origin": {
            "ELEMENT": "b645c976-4ea1-4331-83d8-61c23ec1d5af",
            "element-6066-11e4-a52e-4f735466cecf": "b645c976-4ea1-4331-83d8-61c23ec1d5af"
          }
        }
      ]
    }
  ]
}
1550669271021   Marionette      DEBUG   0 -> [0,77,"WebDriver:PerformActions",{"actions":[{"actions":[{"duration":100,"origin":{"element-6066-11e4-a52e-4f735466cecf":"b64 ... 23ec1d5af"},"type":"pointerMove","x":0,"y":0}],"id":"default mouse","parameters":{"pointerType":"mouse"},"type":"pointer"}]}]
1550669271155   Marionette      DEBUG   0 <- [1,77,null,{"value":null}]
1550669271156   webdriver::server       DEBUG   <- 200 OK {"value":null}

And this one failed to hover (second one):

1550669286704   webdriver::server       DEBUG   -> POST /session/e6683c10-61c0-460a-8af9-c5358dda9358/elements {
  "value": ".collection-table-row",
  "using": "css selector"
}
1550669286708   Marionette      DEBUG   0 -> [0,78,"WebDriver:FindElements",{"using":"css selector","value":".collection-table-row"}]
1550669286727   Marionette      DEBUG   0 <- [1,78,null,[{"element-6066-11e4-a52e-4f735466cecf":"b645c976-4ea1-4331-83d8-61c23ec1d5af"},{"element-6066-11e4-a52e-4f735466c ... ecf":"8cfecfe9-d4e8-4ca7-8c42-767a875f453f"},{"element-6066-11e4-a52e-4f735466cecf":"9a30adac-5b61-4126-8717-b15096e203fd"}]]
1550669286728   webdriver::server       DEBUG   <- 200 OK {"value":[{"element-6066-11e4-a52e-4f735466cecf":"b645c976-4ea1-4331-83d8-61c23ec1d5af"},{"element-6066-11e4-a52e-4f735466cecf":"01d2700d-e871-42b7-bd94-f183fabdfc8e"},{"element-6066-11e4-a52e-4f735466cecf":"0bb5553f-ea8a-49e9-b5dc-81713624f187"},{"element-6066-11e4-a52e-4f735466cecf":"72179192-0c6a-400e-9c9f-7168b5f663ff"},{"element-6066-11e4-a52e-4f735466cecf":"89ef2348-4cf8-4a13-8405-48ac1979f34d"},{"element-6066-11e4-a52e-4f735466cecf":"386ef913-4e55-4190-ae83-5e72b1801d40"},{"element-6066-11e4-a52e-4f735466cecf":"6b8606cc-0227-4c17-a497-db807bd42b57"},{"element-6066-11e4-a52e-4f735466cecf":"8cfecfe9-d4e8-4ca7-8c42-767a875f453f"},{"element-6066-11e4-a52e-4f735466cecf":"9a30adac-5b61-4126-8717-b15096e203fd"}]}
1550669286760   webdriver::server       DEBUG   -> POST /session/e6683c10-61c0-460a-8af9-c5358dda9358/actions {
  "actions": [
    {
      "id": "default mouse",
      "type": "pointer",
      "parameters": {
        "pointerType": "mouse"
      },
      "actions": [
        {
          "duration": 100,
          "x": 0,
          "y": 0,
          "type": "pointerMove",
          "origin": {
            "ELEMENT": "b645c976-4ea1-4331-83d8-61c23ec1d5af",
            "element-6066-11e4-a52e-4f735466cecf": "b645c976-4ea1-4331-83d8-61c23ec1d5af"
          }
        }
      ]
    }
  ]
}
1550669286767   Marionette      DEBUG   0 -> [0,79,"WebDriver:PerformActions",{"actions":[{"actions":[{"duration":100,"origin":{"element-6066-11e4-a52e-4f735466cecf":"b64 ... 23ec1d5af"},"type":"pointerMove","x":0,"y":0}],"id":"default mouse","parameters":{"pointerType":"mouse"},"type":"pointer"}]}]
1550669286895   Marionette      DEBUG   0 <- [1,79,null,{"value":null}]
1550669286896   webdriver::server       DEBUG   <- 200 OK {"value":null}

EDIT: This might be Firefox version related issue, it works fine on Firefox 63.0.1 and 64.0.2

[snowymike]

this may be the same issue i sent to the selenium users google group at https://groups.google.com/forum/#!topic/selenium-users/JYJKHUa0hdM

my focus (really hover) issues began with Firefox 65. 64.0 worked fine. 65.0.2 32-bit works fine. 65.0.2 64-bit does not.

@acikojevic did you by chance try Firefox 65 32-bit to see if that works? if it does, i think our issues are identical.

[snowymike]

Firefox 66.0, 64-bit, has the same problem

[snowymike]

@whimboo is there still reporter feedback you are looking for on this one or is @acikojevic 's trace log sufficient?

[whimboo]

@snowymike we are currently limit in doing work on geckodriver, sorry. So any additional feedback from you and others would be welcome. Given that 64 was working for you, it would be good to know when during the Firefox 65 development process the issue started for you. Maybe you could check the beta versions of Firefox and tell me in which of those it started for you? It would make it easier to pinpoint the underlying change. Those builds can be found at http://archive.mozilla.org/pub/firefox/releases/.

[snowymike]

@whimboo i'll try to narrow down which 65 beta broke things. i just tried 66.0.1 today, focus still messed up there.

[snowymike]

it's broken in the first 65 beta i see at that link, 65.0b3, http://archive.mozilla.org/pub/firefox/releases/65.0b3/win64/en-US/

it was tricky to avoid auto-update happening. unchecking the Mozilla Maintenance service during install wasn't enough to block it. i ended up unchecking launch firefox at install completion, such that the first run of firefox was through geckodriver, as the way to keep the version at 65.0b3.

[whimboo]

Mind also testing the devedition releases which would be beta 1 and 2? You can find those here: https://archive.mozilla.org/pub/devedition/releases/

This seems to be similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1538486.

[snowymike]

beta 1 also broken

[snowymike]

@whimboo any other info that would be helpful for me to provide?

[snowymike]

not fixed in 66.0.3 either.

any update on this issue? i haven't seen anything new posted here or at https://bugzilla.mozilla.org/show_bug.cgi?id=1538486 in the last month.

[whimboo]

Sorry, but I'm currently working on a different project. So I don't have the time to follow on all the bugs/issues for geckodriver.

What would be necessary now is a regression test based on Nightly versions of Firefox. That would help us to pinpoint the change in behavior to a single day, and that might indicate which change caused it.

Based on the release calendar Firefox 65 was on mozilla-central from 2018-10-22 to 2018-12-10. A bisect for those builds would be necessary. Would you mind doing that?

We have a tool called mozregression where you could automate that, or you can use mozdownload to grab specific versions of Firefox Nightly.

Thanks!

[snowymike]

i'll need something i can run on windows. looking at the mozregression and mozdownload links you sent, i'm not certain how precisely i'd get an installer for 64-bit windows for a certain date. if you can share the commands for how i'd get, for example, a 2018-11-10 build of Firefox 65 for 64-bit windows, i'll give it a shot.

[JessefSpecialisterren]

@snowymike Direct downloads of older nightlies can be found at https://archive.mozilla.org/pub/firefox/nightly/2018/ , but automating the regression test should save you a lot of clicking through installers and stuff 😉. There's a windows installer for mozregression as documented at https://mozilla.github.io/mozregression/install.html , and there's a quick start video tutorial at https://mozilla.github.io/mozregression/quickstart.html

[whimboo]

In the case you don't want to use mozregression, for mozdownload just use mozdownload -t daily --date 2018-11-10. The command will automatically pick the correct platform based on what you are working with. If not there is still -p win64 available to force Windows 64bit binaries. Thanks!

[snowymike]

it's broken in the very first nightly build of 65

https://archive.mozilla.org/pub/firefox/nightly/2018/10/2018-10-22-22-07-34-mozilla-central/firefox-65.0a1.en-US.win64.installer.exe

it works properly in the final nightly build of 64

https://archive.mozilla.org/pub/firefox/nightly/2018/10/2018-10-22-10-00-55-mozilla-central/firefox-64.0a1.en-US.win64.installer.exe

[whimboo]

Thanks a lot @snowymike! Now lets move further investigation to the before-mentioned bug.

[snowymike]

i don't have a bugzilla account to post it there, but fyi, the moz:useNonSpecCompliantPointerOrigin setting discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1538486 does avoid the focus problem in my test. @whimboo would you mind reporting that there?

i added this one line

		options.setCapability("moz:useNonSpecCompliantPointerOrigin", true);

to my existing method below

	private static FirefoxOptions getGeckoFirefoxOptions(String locale) {
		FirefoxOptions options = new FirefoxOptions();
		FirefoxProfile profile = new FirefoxProfile();
		profile.setPreference("intl.accept_languages", locale);
		// avoid the dialog that appears when saving zip files (e.g. for export)
		profile.setPreference("browser.helperApps.neverAsk.saveToDisk", "application/zip");
		options.setCapability(FirefoxDriver.PROFILE, profile);
		options.setCapability("moz:useNonSpecCompliantPointerOrigin", true);
		return options;
	}

and that worked in Firefox 66.0.5 64-bit Windows

[whimboo]

Thanks! I will add a comment on the bug for that.

[whimboo]

Since this bug was laying around for a while and users were forced to set the moz:useNonSpecCompliantPointerOrigin capability, I was trying to reproduce the problem again but I'm not able to with a recent Nightly build of Firefox.

@snowymike, @acikojevic or @insight do you still run into it with moz:useNonSpecCompliantPointerOrigin set to false?

[whimboo]

Actually I was able to reproduce it with a Firefox 78 build. More testing revealed that this issue is gone since the Firefox 84 release. For more details see https://bugzilla.mozilla.org/show_bug.cgi?id=1538486.

[snowymike]

@whimboo so no need for

options.setCapability("moz:useNonSpecCompliantPointerOrigin", true);

in builds 84 or newer, correct?

[whimboo]

@snowymike yes that would be correct. I would appreciate if you could test your specific example(s) and report back. Thanks!

[snowymike]

@whimboo sorry for the delay

i find i still need the workaround in version 112 of Firefox, 64-bit, on Windows 11. i first confirmed things didn't work with geckodriver 0.30.0, 64-bit, Windows, then tried the latest, 0.33.0 and have the same issue. the tests we have that focus on a text input in order to dismiss a popover in another part of the screen, that initially started failing in Firefox with version 65, do not work without the workaround of:

options.setCapability("moz:useNonSpecCompliantPointerOrigin", true);

[jeremy-of-laurel]

Hi @whimboo ,

This is still broken as of Firefox 119 and geckodriver 0.33.0. Additionally, the workaround using the above capability no longer works because it is no longer supported as of version 116.

So currently, versions 116 and later are not testable on my end because many of my tests perform multiple hovers on the same element. The only workaround I have for now is to remain on version 115, which isn't a great long term solution.

Any additional attention to this issue would be greatly appreciated.

[whimboo]

@jeremy-of-laurel would you mind filing a new issue for it and if possible attaching a testcase that could be used to reproduce - maybe even with some lightweight HTML?

Note that we were asking via various channels if anyone is still using this capability but we didn't get any reply. As such we decided to remove it due to no known problems with the WebDriver API. When you provided the details we can clearly have a look.

[luke-hill]

FYI I'm aware this is semi-ancient. But I've found a similar use case. I was originally directed after googling a bug for capybara and found this. teamcapybara/capybara#2156

I think "part" of the issue, is that chrome hovering works differently (It seems), to firefox. I've been discussing in #selenium on slack to see if the issue boils down to your "current" focus point being identical to the requested "hover point"

Firefox: v121
Gecko: 0.33
OS: Ubuntu 20.04

Can I ask whimboo that If I am "on" element A, i.e. it's highlighted in the background. But no dropdown is there, should hovering on element A be permissible. It is on chrome that is also running locally with latest versions.

EDIT: I am not using any special capabilities. I am also not able to reliably share the html (As it is behind a login wall). The problem is demonstrable if you have a dropdown that requires a hover, and it is "highlighted" (Through maybe some other means). A rudimentary image of my situation is below

Because it has some sort of "latent" state, #hover doesn't seem to work on the Submissions v dropdown in the nav bar on Firefox. But it does on Chrome.

[luke-hill]

Any news on this @whimboo - Could we get this re-opened as this has regressed?

[whimboo]

@luke-hill would you mind filing a new issue for your problem? Also a minimized HTML with such a dropdown would be kinda helpful.

[luke-hill]

Hi @whimboo - I'm not sure how easy it is to replicate a minimized html file. I will however file a new issue.