1538486 - Cannot hover on Button twice

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect, P3)

Description

[Gevorg]

Attachment: FirefoxHoverIssue-master.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Steps to reproduce:

1. Create webdriver instance.
2. Go to "https://www.google.com" page.
3. Hover on "Google Search" button.
4. Make sure that button's color changed.
5. In same instance of webDriver repeat steps 2-4 .

Actual results:

In the first time the "Google Search" button changed the color as expected, but in the next steps button is not hovered.

Expected results:

The "Google Search" button should be hovered and changed the color as expected.

Comment 1

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

Is that a problem which started to happen with Firefox 65? Did Firefox 64 work for those steps?

Comment 2

[Gevorg]

No, Firefox 64 version not work for those steps.

Comment 3

[Gevorg]

Sorry, In Firefox 64 work for those steps.

Comment 4

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

Interesting. This has the same regression range like https://github.com/mozilla/geckodriver/issues/1507. We currently track down the version on that github issue.

Comment 5

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

As investigated on https://github.com/mozilla/geckodriver/issues/1507 this regressed on 2018-10-22 with the following changes:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43d78c2bd006d7cf7d90508519c8aa88be18ab0c&tochange=2872e7a3606d6108874930a1eb4062c74bad0e9e

Andreas, could it be that bug 1499360 is the culprit here?

Comment 6

[Andreas Tolfsen ❲:ato❳]

That seems likely, because dispatchPointerMove relies on
element.getInViewCentrePoint to get the origin element’s centre
point, and that is used as the basis for the X/Y offset of how far
to move the pointer.

One of the trace logs shows a pointerMove action defined this
way:

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

If the first client rect of origin is sufficiently small, say 1x1
px, the centre point is calculated to be (0,0) in order for
DOMElement.elementsFromPoint to get the correct paint tree. If
the centre point was (1,1) and the element 1x1 px, the paint tree
coordinate would be outside the bounds of the element.

If you give x and y in the above example the values of 1, I
suspect the test will pass. This leads me to wonder if
element.getInViewCentrePoint should not ceil the value, and that
WebDriver should subtract 1 px when calling DOMElement.elementsFromPoint
instead…

It would be interesting to know what the x/y coordinates computed
by element.getInViewCentrePoint are? It would also be great to
have a reduced test case. I suspect a 1x1 px <div> reacting in
some way to being hovered with pointerMove should be sufficient.

We can also test this theory by setting the
moz:useNonSpecCompliantPointerOrigin capability to true. This
should avoid calling element.getInViewCentrePoint and instead use
element.coordinates.

Comment 7

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

As additionally noted on the Github issue enabling moz:useNonSpecCompliantPointerOrigin via the capabilities causes this problem to disappear.

Comment 8

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

I tried to replicate this bug but I'm not able to. At least in recent versions of Firefox it works just fine and it doesn't matter which value moz:useNonSpecCompliantPointerOrigin actually has. The Marionette testcase that I've used is:

    def test_actions(self):
        url = inline("""
            <style>
              body {
                margin: 0;
                padding: 0;
              }
              div {
                width: 100px;
                height: 100px;
                background: red;
              }
              div:hover {
                background: green;
              }
            </style>
            <div id="foo"></div>
            """)

        self.marionette.navigate(url)
        elem = self.marionette.find_element(By.ID, "foo")

        mouse_chain = self.marionette.actions.sequence(
            "pointer", "pointer_id", {"pointerType": "mouse"}
        )
        mouse_chain.pointer_move(0, 0, origin=elem).perform()
        self.marionette.actions.release()

        self.marionette.navigate(inline("<div>other page</div>"))
        self.marionette.go_back()
        elem = self.marionette.find_element(By.ID, "foo")

        mouse_chain = self.marionette.actions.sequence(
            "pointer", "pointer_id", {"pointerType": "mouse"}
        )
        mouse_chain.pointer_move(0, 0, origin=elem).perform()
        self.marionette.actions.release()

I've asked on the github issue for geckodriver if someone can still reproduce. If not I think that we can go ahead and close this issue as WFM.

Gevorg, I know it's been a while but maybe you can check yourself? Thanks!

Comment 9

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

Actually I tried with an Firefox 78.0 build and I was able to reproduce the problem with the above mentioned Marionette script. After the navigation and returning to the original page the hover was still present. When testing following releases the first one which doesn't show this issue anymore is Firefox 84. With this release we enabled our JSWindowActor infrastructure for Fission by default, and I'm sure that this fixed it.

Gevorg, if you can still see it please reopen the bug. Otherwise I consider this bug as WFM.