Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tomasmatus opened this issue Oct 29, 2024 · 2 comments
Open
Labels

Comments

@tomasmatus
Copy link
Member

tomasmatus commented Oct 29, 2024

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

@tomasmatus tomasmatus added the bug label Oct 29, 2024
@martinpitt
Copy link
Member

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
Copy link
Member

jelly commented Oct 30, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants