search

cockpit-project / cockpit

Cockpit is a web-based graphical interface for servers.
http://www.cockpit-project.org/
GNU Lesser General Public License v2.1
11.33k stars 1.13k forks source link

testlib: using `b.mouse(..., ctrlKey=True)` keeps the ctrl modifier active #21187

Open tomasmatus opened 4 weeks ago

tomasmatus commented 4 weeks ago

Explain what happens

When using b.mouse() with ctrl key modifier in Firefox the modifier is kept active for all future b.mouse() calls.

I am not sure if this is a bug in testlib or something in firefox bidi driver.

Relevant testing farm failure: https://artifacts.dev.testing-farm.io/650d6b68-b518-414e-9ff2-d2b8f8d73939/

Relevant part of testNavigation: First in the test ctrl modifier is used

        m.execute("touch /home/admin/newfile.txt")
        b.mouse("[data-item='newfile.txt']", "click", ctrlKey=True)
        b.wait_in_text(".files-footer-info", "2 files selected")
        b.mouse("[data-item='tmplink']", "click", ctrlKey=True)
        b.wait_in_text(".files-footer-info", "3 files selected")

and then later on in the test there is another use of b.mouse this time with ctrlKey=False (default). Testingfarm log shows the test fails here.

        # Navigating resets the current search filter
        b.set_input_text("input[placeholder='Filter directory']", "sys")
        self.browser.wait_js_cond("ph_count('#folder-view tbody tr') == 1")

        b.mouse("[data-item='sys']", "dblclick")
        self.assert_last_breadcrumb("sys")

problem also persists when explicitly setting it to false in the function call.

The bidi input action looks good to me.

INFO:bidi.command:← input.performActions({'context': '10737418243', 'actions': [{'id': 'pointer-390', 'type': 'pointer', 'parameters': {'pointerType': 'mouse'}, 'actions': [{'type': 'pointerMove', 'x': 0, 'y': 0, 'origin': {'type': 'element', 'element': {'type': 'node', 'sharedId': '603c86a6-fd58-448e-a526-157f182de9e6', 'value': {'nodeType': 1, 'localName': 'tr', 'namespaceURI': 'http://www.w3.org/1999/xhtml', 'childNodeCount': 5, 'attributes': {'class': 'pf-v5-c-table__tr folder', 'data-ouia-component-type': 'PF5/TableRow', 'data-ouia-safe': 'true', 'data-ouia-component-id': 'OUIA-Generated-TableRow-2', 'data-item': 'sys'}, 'shadowRoot': None}}}}, {'type': 'pointerDown', 'button': 0}, {'type': 'pointerUp', 'button': 0}, {'type': 'pointerDown', 'button': 0}, {'type': 'pointerUp', 'button': 0}]}]}) [id 390]

Version of Cockpit

327

Where is the problem in Cockpit?

None

Server operating system

None

Server operating system version

No response

What browsers are you using?

Firefox

System log

No response

martinpitt commented 3 weeks ago

Can you reproduce this locally? If so, can you please paste a full run with --trace? I just checked def mouse(), and 

        if ctrlKey:
            keys_pre.append(key("keyDown", "Control"))
            keys_post.append(key("keyUp", "Control"))

seems correct to me, I don't see typos. In the log I'd like to see that the "keyUp Control" is actually ran. If so, then it rather smells like a firefox bug. Do you know, is that only Control, or also affects Alt/Shift/Meta?

jelly commented 3 weeks ago

Another example which is still around is https://github.com/cockpit-project/cockpit-files/blob/main/test/check-application#L819