action #55703
closed
send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly
Added by SLindoMansilla over 5 years ago.
Updated over 4 years ago.
Category:
Feature requests
Estimated time:
(Total: 126.00 h)
Description
Observation¶
After several issues with "missing keys" when modifiers+normal_keys are involved, we realized that we can reproduced the same issues that openQA was showing by manually pressing the two keys simultaneosly. Those experiments, while far from being a scientific prove, help us understand what could be going wrong.
Different applications handles those keys different (eg. gedit, firefox).
Suggestion¶
- Be sure that when using send_keys(), they are sent in the positional order. (eg. if alt-a is sent, alt should be sent first and then 'a', with enough time to let the application handles them.
- Check with coolo about implementation of the VNC wrapper.
- Subject changed from [epic] send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly to [epic][functional][u] send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly
- Status changed from New to Workable
- Related to action #39926: [functional][u][sporadic][virtio] test fails in vlc - vlc is started twice, needle target_match_vlc seems wrong added
- Related to coordination #43889: [qe-core][epic][functional][virtio][wayland] openQA makes spelling mistakes added
- Assignee changed from SLindoMansilla to mgriessmeier
- Blocks action #54056: [functional][u] test fails in virtman_view added
it seems that the PR doesn't solve our issue: #54056: [functional][u] test fails in virtman_view
- Blocks deleted (action #54056: [functional][u] test fails in virtman_view)
- Project changed from openQA Tests (public) to openQA Project (public)
- Subject changed from [epic][functional][u] send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly to send_keys() doesn't guarantee that the application will handle modifiers+normal_key properly
- Category changed from Bugs in existing tests to Feature requests
- Status changed from Workable to New
- Assignee deleted (
mgriessmeier)
- Target version set to Ready
- Related to action #54056: [functional][u] test fails in virtman_view added
The relation helps us in our queries to know that someone is working on that so that we don't duplicate tickets/efforts
I just removed the 'blocked by' as it's obviously not blocked by this - as seen by the PR
send_key does not care about VNC_TYPING_LIMIT contrary to type_string.
We could try to update send_key to respect VNC_TYPING_LIMIT and if it is not enough, we could implement a slow_send_key or add an arg to send_key to adjust it, as suggested by @coolo.
that sounds like a very good idea.
I would make the default slower in general - the typing limit should be respected nonetheless
- Status changed from New to Feedback
- Assignee set to coolo
- Target version changed from Ready to Current Sprint
- Status changed from Feedback to Resolved
we're good. So far no complains about typing too slow - and actually fixing some cases
Also available in: Atom
PDF