Command-click does not work correctly in test directory lists

[bzbarsky]

STEPS TO REPRODUCE:

1) Use a Mac. 2) Load https://wpt.fyi/results/ 3) Hold down the "Command" key and click on the "2dcontext/" text.

EXPECTED RESULTS: Opens the "2dcontext" results in a new tab.

ACTUAL RESULTS: Opens them in the same tab, overwriting the list I am still trying to go through. This is happening in Chrome, Safari, and Firefox, so this is not a browser bug; it's clearly a bug in the web page.

If these blue things are normal links, this should Just Work. Presumably the page is binding (broken!) click event handlers to them instead of just making them normal links that would behave like users expect links to behave...

I expect https://github.com/web-platform-tests/wpt.fyi/issues/193 is somewhat related, but again this is broken in every single browser I have access to.

I should note that the link to the revision id (right now d892efb842) in the column headers works correctly.

[bzbarsky]

@lukebjerring How does that change fix this problem? event.ctrlKey is false for Command+click on Mac, no?

[lukebjerring]

Reopened because, as pointed out by @bzbarsky, Cmd is not considered a modifier key, so this is not a fix. Fix is not trivial.

I'm not convinced a bunch of extra code for keypresses is justified; right click and open in new tab should suffice, though annoying. Navigating without a full reload is an important optimization.

[bzbarsky]

Cmd is totally a modifier key. It's just not ctrlKey. It's metaKey.

right click and open in new tab should suffice,

It's a huge PITA, actually. Much slower than modifier+click.

More importantly, it's a ton of mental overhead. So the practical effect is to modifier+click, curse, hit the back button, then have to use the context menu. Note that this is way slower than even a full reload would be.

In practice, for my use cases, I never want to look at only one thing on wpt.fyi, for what it's worth. It would almost be better for me if it always opened things in new tabs.

[lukebjerring]

Segway: @bzbarsky - we're currently brainstorming some changes to the ui to improve "browseability" of the data. Sounds like there's a good chance your use case could be improved; would you be able to elaborate on what it is you're opening/comparing/browsing as a typical use of wpt.fyi?

[bzbarsky]

I have three things I do, recently. In decreasing order of time spent:

1. Pick a directory, and drill down through it to find all the test failures for Firefox in that directory and see what they are and how to fix them.

2. Have a specific test, look up whether different browsers pass it. For this use case, having the search/filter field works pretty well, though it would be even better if it automatically "opened" directories if all the hits are inside a given directory.

3. Pick a directory that has all browsers failing tests, drill down to see whether there are specific tests that everyone fails (which often indicates a buggy test or buggy standard or some other issue along those lines).