It is not possible to select text in either the Compare or Preliminary Check tables.
So, for example, you cannot copy an IP or user agent.
@dbarratt Has commented: maybe we took over the click handler... ?
Wiki(s): https://test.wikipedia.org MediaWiki 1.36.0-wmf.6 (rMW6e5e4db172cb) 11:43, 26 August 2020.
Browsers: Firefox 68 and Chromium 83.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Remove highlighting on focus in Special:Investigate | mediawiki/extensions/CheckUser | master | +3 -15 |
I think this is because of the mousedown handler https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/620798/6/modules/ext.checkuser.investigate.tables.js#234
@Prtksxna @Niharika We intercept the mousedown event to prevent a number of bugs/undesired behaviours that happen if you allow focus on click. They're summarised in this comment from the original task: T260217#6393488
We could fix this problem by restoring the focus to the previous element that was focused before the click. Basically:
Theoretically that should fix the problem.
This would cause conflicting highlights to appear between mousedown and mouseup. (Theoretically one could add some class preventing that, as discussed elsewhere.) However, doing these hacks adds complexity and fragility to the codebase, which I don't feel is worth it; I can imagine us spending time chasing bugs related to these interactions, and finding it difficult to build on top of them without breaking them again.
@Prtksxna @Niharika How important is highlight on keyboard focus vs the ability to select text?
For what it's worth, I think that the highlight on focus is causing too many problems. The highlights on focus cause a bug where keyboard highlights can conflict with mouse highlights (T260217#6393488 - see end of comment). Another example is this ticket.
Keyboard navigation is already buggy, due to inconsistencies between browsers (T262543) and unexpected behaviour in the OOUI widgets (T261862, T261762). These problems mean that keyboard navigation is only partially supported anyway, so it seems reasonable to consider the highlighting behaviour as a progressive enhancement, not available in keyboard-only environments.
If we removed highlight on focus, we text selection would be enabled again.
@Prtksxna @Niharika How important is highlight on keyboard focus vs the ability to select text?
@Tchanders Speaking from a CU's perspective, highlight on keyboard focus vs. the ability to select text (and subsequently copy and paste it to CU wiki or an onwiki investigation) - highlight on keyboard focus is a super minor enhancement without much worth whereas select text is a critical function.
I'd definitely say ability to select text, but its sad that it is a choice between that and an a11y feature. While I agree with @DeltaQuad that it is a minor enhancement, it might be important for people who can't use the mouse.
I agree that selection of text will be useful to more people at the moment. We should focus on that.
Just to clarify, this task is not to remove keyboard navigation, it is to remove the color change on table focus (i.e. the highlighting will only happen on hover)
Change 635643 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Remove highlighting on focus in Special:Investigate
Change 635643 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Remove highlighting on focus in Special:Investigate
It is possible to copy text from each column of the Preliminary Check and Compare tables.
You can no longer highlight using the keyboard. However, you can still select a highlight pin with the keyboard, which achieves a very similar thing.
You can still do other things with the keyboard in the table, including selecting items from the ... menu, pinning and sorting columns.
Test environment: Local vagrant MediaWiki 1.36.0-alpha (42fcd02), CheckUser 2.5 (6abbe8d).