Bug 881392 - webadmin: search bar: cannot navigate to the items in the auto-complete pop-up using the keyboard on some browsers
Summary: webadmin: search bar: cannot navigate to the items in the auto-complete pop-u...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.2.0
Assignee: Alexander Wels
QA Contact: Pavel Stehlik
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-28 20:25 UTC by Yaniv Kaul
Modified: 2015-09-22 13:09 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
A keyboard-triggered navigation or selection (e.g. using the keyboard arrow-keys to navigate/select items in the Search-bar auto-complete drop-down items in RHEV-M web-admin) does not work as expected in Firefox when the "Always use the cursor keys to navigate within pages" option is enabled. This option resides in the Firefox 'Preferences' -> 'Advanced' -> 'General' -> 'Accessibility' section and is disabled by default. It is recommended to keep it that way when working with RHEV-M web-applications. Note that hitting the "F7" key in the keyboard while working in Firefox toggles the enable/disable state of this option as well. More information on this Firefox option can be found at: http://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we#w_always-use-the-cursor-keys-to-navigate-within-webpages
Clone Of:
Environment:
Last Closed: 2013-05-01 16:22:40 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Video of me using keyboard to select in FF17 (1.17 MB, video/ogg)
2013-01-09 21:11 UTC, Alexander Wels
no flags Details
Video of me using keyboard to select in FF19 (2.14 MB, video/ogg)
2013-04-12 13:44 UTC, Alexander Wels
no flags Details
Screen-shot from Simon's environment (65.85 KB, image/png)
2013-04-12 14:42 UTC, Einav Cohen
no flags Details
ScreenCaptureSimonDesktop-FF20-Beta2 (6.58 MB, application/octet-stream)
2013-04-26 09:30 UTC, Simon Grinberg
no flags Details
Screenshot of the offending setting (61.21 KB, image/png)
2013-05-01 14:06 UTC, Simon Grinberg
no flags Details

Description Yaniv Kaul 2012-11-28 20:25:05 UTC
Description of problem:
(using ff 17, need to test w/ other browsers)
When trying to write a search term in the search bar, the drop down items cannot be selected via a keyboard, only by mouse click.
Regression from 3.0.

For example:
Hosts: 
Then start 'sort' - it'll complete to 'sortby' - which you cannot select using the keyboard.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Einav Cohen 2012-11-28 22:15:47 UTC
works ok on ff12 (fedora 16)

Comment 3 Einav Cohen 2012-11-28 22:37:45 UTC
what doesn't work exactly? 
can you navigate to the item in the auto-complete list using the up/down keyboard arrows but when pressing on "Enter" it does nothing? 
or navigating to the item using the the up/down keyboard arrows is simply impossible?
or something else?...
[a video would be great]

Comment 4 Yaniv Kaul 2012-11-29 06:18:03 UTC
(In reply to comment #3)
> what doesn't work exactly? 
> can you navigate to the item in the auto-complete list using the up/down
> keyboard arrows but when pressing on "Enter" it does nothing? 
> or navigating to the item using the the up/down keyboard arrows is simply
> impossible?

I cannot navigate down with the keyboard.
> or something else?...
> [a video would be great]

Comment 5 Einav Cohen 2013-01-09 20:55:36 UTC
we cannot reproduce this on Firefox 17 on Fedora 17.

- Which client OS are you using?

- Did you try testing rhev-m 3.2 to see if it reproduces there as well?

Comment 6 Alexander Wels 2013-01-09 21:11:17 UTC
Created attachment 675874 [details]
Video of me using keyboard to select in FF17

Comment 7 Alexander Wels 2013-01-09 21:11:55 UTC
I am unable to reproduce, see attached video for demonstration.

Comment 8 Yaniv Kaul 2013-02-02 18:04:53 UTC
(In reply to comment #5)
> we cannot reproduce this on Firefox 17 on Fedora 17.
> 
> - Which client OS are you using?

FF 18, on Fedora 18.

> 
> - Did you try testing rhev-m 3.2 to see if it reproduces there as well?

No, just RHEVM 3.1.2.

Comment 10 Alexander Wels 2013-03-05 18:13:21 UTC
I just tried with Fedora 18 on FF19 (that was the latest) and I am unable to reproduce. Same results as Fedora 17 and Firefox 17.

Comment 11 Yaniv Kaul 2013-03-06 15:15:04 UTC
(In reply to comment #10)
> I just tried with Fedora 18 on FF19 (that was the latest) and I am unable to
> reproduce. Same results as Fedora 17 and Firefox 17.

Just happened to me today on FF19 on Fedora 18.

Comment 14 Einav Cohen 2013-04-10 14:51:02 UTC
(In reply to comment #7)
> I am unable to reproduce, see attached video for demonstration.

Alex - the attached video is for ovirt. is there a chance that you can check if you can reproduces it for RHEVM-3.2?

Comment 16 Alexander Wels 2013-04-12 13:44:11 UTC
Created attachment 734740 [details]
Video of me using keyboard to select in FF19

The attached video is me using the keyboard to select items in the dropdown using FF19 on Fedora17 with RHEV 3.2. It works perfectly fine for me. This is the latest RHEV 3.2 build.

Comment 17 Einav Cohen 2013-04-12 14:42:49 UTC
Created attachment 734788 [details]
Screen-shot from Simon's environment

In the attached screen-shot, you can see the problem reproduced: when attempting to navigate to the auto-complete drop-down items using the keyboard, the items are not being highlighted as expected; instead, a "text cursor" is appearing on the "navigated" drop-down item, as if the item's text can be edited (pay attention to the item surrounded in purple rectangle in the screen-shot - you will notice the "text cursor" in between the "S" and the "t").

Comment 18 Einav Cohen 2013-04-12 18:25:50 UTC
Alex - as this was reproducible on two clients (rather than one), there is a chance that we are missing something here with regards to the exact reproducible scenario; maybe it reproduces only in the following conditions (or a combination of some of them):

- when attempting to edit the search as the very first action after logging into the application (i.e. not attempting to navigate to other main tabs first or anything like that - login to the application, and go straight to the search bar)

- only on the VMs main tab (see attachment 734788 [details])

- only when the grid is empty (again - see attachment 734788 [details], although in your experiments - you had empty grids as well, I think)

- only before (or only after) the first auto-refresh cycle

- only when your client is not your physical client, but a client to which you are connected with a remote-console session (e.g. VNC, SPICE) - maybe something is messed up with the way that the key-press events are propagated to the remote client.

Can you please try the scenarios above (and maybe also some combinations of them) *on RHEV-M 3.2* on either FF19 on Fedora 18 (which is the platform on which Yaniv Kaul reproducing the problem, but you couldn't) or FF17 on RHEL 6 (which is the platform that we are supposed to formally support) and see if you can somehow reproduce it? 

Also: please see my comment #17 - maybe the behavior that I described there can give you a hint.

Comment 19 Alexander Wels 2013-04-15 20:00:47 UTC
Here are the results of my tests:

- go directly to search, works fine.

- only on the VMs main tab (that is how my videos are) works fine.

- only when the grid is empty works fine.

- only before (or only after) the first auto-refresh cycle. Works fine.

- only when client not physical client. Works fine.

I have been unable to reproduce in any of the presented scenarios. I have however managed to reproduce it once or twice while just clicking around and I have not found any particular pattern. I tried the same sequence again it it works fine. I have a feeling it is some sort of timing issue, but I have not found anything in the code that would indicate a problem.

Could the people reporting this please create a video that shows me EXACTLY what steps they are following to reproduce this? Having a screenshot doesn't help me much in this instance, I need steps to reproduce the problem. I can reproduce it once every 20 or so times, can the reporters reproduce it more reliably?

Comment 20 Einav Cohen 2013-04-16 14:07:20 UTC
(In reply to comment #19)
> 
> Could the people reporting this please create a video that shows me EXACTLY
> what steps they are following to reproduce this? Having a screenshot doesn't
> help me much in this instance, I need steps to reproduce the problem. I can
> reproduce it once every 20 or so times, can the reporters reproduce it more
> reliably?

Simon - any chance that you can provide a video (see above)?
also: are you able to reproduce this in oVirt as well?
[please mention exact OS, browser, etc.]
Thanks in advance.

Comment 21 Simon Grinberg 2013-04-26 08:05:46 UTC
Einav, 
I'll try to upgrade to the latest RHEV release 13.1 and let's see

Comment 22 Simon Grinberg 2013-04-26 09:30:49 UTC
Created attachment 740316 [details]
ScreenCaptureSimonDesktop-FF20-Beta2

Adding a screen capture with:
Desktop OS - Fedora17 with latest updates
RHEVM - 3.2 beta 2 SF13.1
FireFox 20.0 

Still happens.
You can see that the mouse does select while the keys do not (actually seems the operations to be orthogonal) 

Thanks, 
Simon

Comment 23 Einav Cohen 2013-04-26 16:59:26 UTC
Thanks Simon.
Any chance that you can check if it happens to you in oVirt as well (as I requested in Comment #20)?

Comment 24 Simon Grinberg 2013-04-28 12:49:39 UTC
(In reply to comment #23)
> Thanks Simon.
> Any chance that you can check if it happens to you in oVirt as well (as I
> requested in Comment #20)?

Forgot about that, if you remember we did it live on the call where I took the first snapshot - it works well with oVirt 3.2 release so whatever happened it was probably existed before the rebase and fixed by a following commit that was not merged downstream.

Comment 25 Simon Grinberg 2013-05-01 14:06:27 UTC
Created attachment 742218 [details]
Screenshot of the offending setting

More updates:

- Checked with KDE as Alex theory was that it might be related to the desktop - same results. 

- Started playing with Firefox settings and found out that when I disable the option "Always use the cursor keys to navigate within pages" then the problem disappears"

Now need to check why it does not effect the upstream oVirt but just RHEV 3.2 and 3.1.

Comment 26 Einav Cohen 2013-05-01 14:45:10 UTC
Simon - when Alex attempted to reproduce it, it seems to be reproducible in ovirt as well. 

I know that you were NOT able to reproduce the problem in ovirt in the context of Comment #24 (which made you think that the problem has been fixed in ovirt, and that this fix wasn't backported to rhevm-3.2), however IIUC this was before you found out about that "bad" FF option (comment #25).

any chance that you can double-check ovirt and make sure that, like Alex, you ARE able to reproduce the problem when that "bad" FF option is on?

[it seems like we are going to close this BZ on CANT-FIX with a release note: the "bad" FF option is disabled by default, which is good for us; information about this option can be found at: http://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we#w_always-use-the-cursor-keys-to-navigate-within-webpages]

Comment 27 Simon Grinberg 2013-05-01 15:01:14 UTC
(In reply to comment #26)
> Simon - when Alex attempted to reproduce it, it seems to be reproducible in
> ovirt as well. 
> 
> I know that you were NOT able to reproduce the problem in ovirt in the
> context of Comment #24 (which made you think that the problem has been fixed
> in ovirt, and that this fix wasn't backported to rhevm-3.2), however IIUC
> this was before you found out about that "bad" FF option (comment #25).
> 

OK I know what happened. Since I could not connect to the ovirt VM from the laptop browser (I still need to check why) I did it from within the VM which also has fedora and FF of the same versions. 

Turning on the option on the VM browser now produces the same results for oVirt. 

So I can confirm it's also happening in oVirt.

Comment 28 Einav Cohen 2013-05-01 16:22:40 UTC
Many thanks, Simon.
So there is nothing we can do about it really - I am closing on CANT-FIX.
I am flagging with "requires_release_note?" and filling the Doc Text.
I set the Doc Type to Release Note, however not sure if it should be a Release Note or a Known Issue - please feel free to change it as needed. Thanks.


Note You need to log in before you can comment on or make changes to this bug.