1656010 - Provide a contextually appropriate navigation link to https://jgraham.github.io/wptdash/ from the Navigation panel and/or test info boxes

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

In bug 1653986 we added a minimal test info boxes implementation with a link to wpt.fyi in the navigation box. :jgraham has an invaluable tool at https://jgraham.github.io/wptdash/ that provides a higher level cross-cutting view of WPT metadata, including divergences between Firefox, Chrome, and Safari that we should figure out how to link to in a contextually useful fashion. Specifically, I was hoping that we might be able to pre-filter/pre-populate the dashboard constraints so that it is focused on the test file that is linked from, perhaps inside the greater context of the same directory?

:jgraham, what are your thoughts on this? Is this something already possible, or could wptdash be enhanced to do this? My goal would be to make sure the dashboard provides directly useful information related to the test file it's linked from without requiring the user to manipulate the dashboard first. (But providing a means of onboarding so that they could easily permute the configuration they're linked to to explore more.)

Comment 1

[James Graham [:jgraham]]

I don't think it's already possible. At the moment you can just link to a specific component, and we can know what component the test is in, so we can do that part. Doing more would require changes on the wptdash side; it doesn't have any way to link to a specific test at the moment, and depending on the filters that are applied, a given test might not appear in the default view. So we'd have to think a bit about the UI we want. Probably making something like "if the supplied test is part of the view, open it up to view subtest results and scroll to it" wouldn't be too hard; making something that handles the "test just isn't in the selected test set" case nicely would be harder.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Maybe we could generate a bug component link with an anchor that includes the full (WPT, not mozilla-central) test path and wptdash could be altered to emit id attributes for each path, maybe in this code and/or with magic CSS styling using :target to highlight it? That way if the test is present, it will be scrolled-to and/or highlighted, but if it's not, the user has a useful subset of information to look at?

And I guess something could also be done to emit an info box that says "the test you linked to is awesome and has no issues, but here's other things in the component" if people get confused.

Comment 3

[James Graham [:jgraham]]

So I tried this; now something like https://jgraham.github.io/wptdash/#/mediacapture-streams/MediaStreamTrack-getCapabilities.https.html will open expanded, but the target bit doesn't work; presumably that's only resolved at page load and we haven't created the element at that point. It's probably possible to make something along those lines work though.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Awesome!

Yeah, I think it's a dynamic load issue, as if I do document.location = document.location or document.location.hash = document.location.hash in the console, then the page scrolls to the element and it properly gets highlighted. I think we used to do something like this in searchfox (explicit delayed location update), but it ended up turning out that as long as we created the id element early enough that it wasn't a problem. I think right now the Highlight constructor handles this and is guaranteed to happen before the load event or things like that. Presumably whatever dynamic process triggers the initial content population could tap the location in an effect hook or componentDidMount or whatever.

I think this is now actionable from a searchfox perspective, but I need to focus on non-searchfox stuff for a little bit, so if someone would like to take this on in the meantime:

• The logic that currently pushes the wpt.fyi link is at https://github.com/mozsearch/mozsearch/blob/4a599135f2fc0951e45ebbc44a089cc5a38fa372/tools/src/bin/output-file.rs#L509-L519 and is where we'd want to add the link to wptdash.
• The added logic would likely want to be a modified version of the logic at https://github.com/mozsearch/mozsearch/blob/4a599135f2fc0951e45ebbc44a089cc5a38fa372/tools/src/bin/output-file.rs#L353-L363 which generates the bugzilla link.
• The end URL would want to look something like https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Adom%3A+editor#/editing/event.html