Change 620798 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/extensions/CheckUser@master] Add the table cells on the Compare tab to the tabindex

https://gerrit.wikimedia.org/r/620798

This was exactly what we expected! woot!

This now works as described. It's way better than it was before, and we can merge as-is if we want.

I did learn something new today, that a mouse click brings the clicked element into focus. This isn't really all that visible in the browser until you explicitly highlight it like we are now. Now clicking on a cell "pins" that cell. This is removed if the user clicks outside the table and the cell matching changes immediately if you hover on another cell...

The only question remaining is how hover and focus should interact (if they should at all). The browser treats these things as independent actions. Our table now does too, except for cell matching. Right now we match (or unmatch) on whichever action was most recent: focusin, focusout, mousein, mouseout. I thought about clearing the focus of an element when a mouse moves, but that seems way wrong. We could do the opposite and disable the mousein mouseout when a table cell (or its contents) has focus, but that seems somewhat unexpected (unless I guess we had an onclick on the focused cell to remove focus or something?). We could match both what is focused and what is hovered, though that could be more even more confusing?

I'm really not sure what the least confusing option is. What we have in this patch (last action wins) isn't terrible, in fact, it's way better than the previous behavior, so I'm happy with it, just wanted to point out the oddness of the focus/hover interaction.

@Prtksxna & @Tchanders what are your thoughts?

Unrelated, but with this patch, I found myself trying to use the arrow keys on my keyboard to move around the table.... that might be a good follow up feature. :)

Thanks @dbarratt - the keyboard interaction works well and improves on what was already there.

In T260217#6391230, @dbarratt wrote:

I did learn something new today, that a mouse click brings the clicked element into focus. This isn't really all that visible in the browser until you explicitly highlight it like we are now. Now clicking on a cell "pins" that cell. This is removed if the user clicks outside the table and the cell matching changes immediately if you hover on another cell...

@Prtksxna I think we should avoid focusing the cell on click (I've suggested a fix on the patch), since it creates some confusing behaviour. Here are some examples:

1. Clicking on one cell then hovering on another causes a highlighting conflict:

2. Pin a cell...

3. Open a menu in one cell...

...then pin another cell in the same group. The toggle button stays visible in the original cell, even when hovering away...

...again, it's not clear what's going on unless the user understands the focus behaviour.

The only question remaining is how hover and focus should interact (if they should at all). The browser treats these things as independent actions. Our table now does too, except for cell matching. Right now we match (or unmatch) on whichever action was most recent: focusin, focusout, mousein, mouseout. I thought about clearing the focus of an element when a mouse moves, but that seems way wrong. We could do the opposite and disable the mousein mouseout when a table cell (or its contents) has focus, but that seems somewhat unexpected (unless I guess we had an onclick on the focused cell to remove focus or something?). We could match both what is focused and what is hovered, though that could be more even more confusing?

@Prtksxna The screenshot of the conflicting highlights above shows what this looks like. I'm inclined to think this is probably acceptable as long as it can only happen if the user is interacting with both the keyboard and the mouse at the same time - i.e. we treat that as an edge case that the user shouldn't be doing. What are your thoughts?

In T260217#6393488, @Tchanders wrote:

@Prtksxna I think we should avoid focusing the cell on click (I've suggested a fix on the patch), since it creates some confusing behaviour.

Yep! That makes sense.

In T260217#6391275, @dbarratt wrote:

Unrelated, but with this patch, I found myself trying to use the arrow keys on my keyboard to move around the table.... that might be a good follow up feature. :)

This would be awesome.

Change 620798 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add the table cells on the Compare tab to the tabindex

https://gerrit.wikimedia.org/r/620798

With the keyboard, I can successfully:

• Start a New investigation
• View the Logs
• Use the Block form, add remove targets and submit a block
• Use the filter form and submit a filter and new date range
• Sort columns
• Highlight IPs and username (and Date attached and Wiki columns in the Preliminary Check tab)
• Use the tool menu for IPs
• Use the pin for IPs and UAs (and Date attached and Wiki for Prelim.)
• Use the tour, including going to each of the steps, dismissing and restarting
• Copy to wikitable
• Go to the different tabs
• Use pagination

@Prtksxna @dbarratt I had a few observations while I've been using it, and would like your opinion about them. Happy to raise bugs if necessary:

• I find if an IP or UA cell has focus, if I hover over the cell or a matching one and hover out the highlighting goes away except for the focused cell. I guess this is what David was talking about in T260217#6391230.

• Thalia mentions this in T260217#6393488, but I can highlight more than one column now. This might actually be a nice feature (minus the highlighting conflict) :)

• I cannot tab to the tools menu unless it is visible. Therefore, I cannot tab to the tools menu in the Username column. Also, if there is another cell highlighted (that doesn't match the current cell), I cannot tab to the menu in the IP column, because the tool menu is only visible when a cell highlights.

• I can use the block form just with the keyboard. However, I find when I am in the user input field if I tab that behaves the same as pressing enter, so hard to tab out of the input without accidentally selecting/unselecting a target. This also occurs in Special:InvestigateBlock and the filters input sometimes (I think I need to raise a bug on the latter). For example:

• It is possible to use the keyboard to open (and use) the Filters menu, but it does not always show any indication that it has focus (e.g. a dotted border).

• When one of the tool menu items has focus, if I press tab it submits/follows the link (I would expect it to dismiss the menu instead)

• I can only get to the tool menu and pin icons by tabbing forward. I cannot by tabbing backwards (shift+tab). (Except for the Wiki column in Preliminary tab)

• You can really mess with the GuidedTour now ;). You can interact with the table using the keyboard, disrupt the highlighting, add a target to investigation, etc.

Test environment: All this was tested on Firefox 68, on my local vagrant MediaWiki 1.36.0-alpha (74a9022) CheckUser 2.5 (5d29e23).

In T260217#6402731, @dom_walden wrote:

• It is possible to use the keyboard to open (and use) the Filters menu, but it does not always show any indication that it has focus (e.g. a dotted border).

I consistently see:

In T260217#6404956, @Prtksxna wrote:

In T260217#6402731, @dom_walden wrote:

• It is possible to use the keyboard to open (and use) the Filters menu, but it does not always show any indication that it has focus (e.g. a dotted border).

I consistently see: ... Might be something worth reporting.

Ah, so do I when I use Chromium. I guess it is a Firefox thing. I may report it, but if it is a browser bug I am not sure there is much we can do.

In T260217#6402731, @dom_walden wrote:

• I cannot tab to the tools menu unless it is visible. Therefore, I cannot tab to the tools menu in the Username column. Also, if there is another cell highlighted (that doesn't match the current cell), I cannot tab to the menu in the IP column, because the tool menu is only visible when a cell highlights.

Raised T261651.

In T260217#6402731, @dom_walden wrote:

• I can use the block form just with the keyboard. However, I find when I am in the user input field if I tab that behaves the same as pressing enter, so hard to tab out of the input without accidentally selecting/unselecting a target. This also occurs in Special:InvestigateBlock and the filters input sometimes (I think I need to raise a bug on the latter). For example:

Raised as T261762.

I am finding that support for tabbing isn't so good on Safari and Firefox on Mac (but Chrome on Mac works well, like Chrome on other platforms).

For example,

• on Safari and Firefox you cannot access other tabs (e.g. Account Information or Timeline) or use pagination
• on Safari you cannot submit the filters form (cannot tab to the "Submit" button)
• on Firefox you cannot access the tools menu or pin icon
• on Firefox you cannot use the block form or copy to wikitext

Tested Mac Catalina with Safari 13.1 and Firefox 80 (on browserstack).

Firefox and Chrome on Windows 10 has good support (i.e. you can perform every action listed above with the keyboard T260217#6402731)

In T260217#6402731, @dom_walden wrote:

• When one of the tool menu items has focus, if I press tab it submits/follows the link (I would expect it to dismiss the menu instead)

Raised as T261862.

In T260217#6430478, @dom_walden wrote:

• on Safari and Firefox you cannot access other tabs (e.g. Account Information or Timeline) or use pagination

Testing on a physical Mac, much of the above "bugs" I identified were actually bugs in how Browserstack (and SauceLabs in fact) emulates tabbing behaviour.

However, there appears to be one legitimate bug: T262543.

I think this covers all the issues I had to raise with this ticket (apart, perhaps, from the issue David raised T260217#6391230, but I don't know if there is an obvious solution).

I am going to move it along as I don't think there is anymore for me to do.

Some issues that I am seeing:

• When you tab to a Username cell, the ellipsis button is hidden and you can't tab to it (or its menu)
• When something is pinned, no other cells show the ellipsis button when focussed

As Dom, noted there is inconsistency in how Safari and Firefox show and allow interactions on focussed elements. Should those issues be raised as part of CheckUser, OOUI or MediaWiki?

In T260217#6516024, @Prtksxna wrote:

Some issues that I am seeing:

• When you tab to a Username cell, the ellipsis button is hidden and you can't tab to it (or its menu)
• When something is pinned, no other cells show the ellipsis button when focussed

As Dom, noted there is inconsistency in how Safari and Firefox show and allow interactions on focussed elements. Should those issues be raised as part of CheckUser, OOUI or MediaWiki?

Have these been fixed in T261651?

In T260217#6517008, @dom_walden wrote:

Have these been fixed in T261651?

Yep, thanks @dom_walden.