1751952 - Filename with line number search (alt: Jump to line when provided <file path>:<line number>)

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

It would be nice if when I searched for 'dom/script/ScriptLoader.cpp:588', it could take me directly to the file-and-line in the results.

Comment 1

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

Would you manually be typing that all out, or is this a case where it might make sense to have some integrating glue in a webextension or a VSCode extension, etc. to better address the motivating use case?

For example, if your use-case is actually:

1. copy file path with colon from an ASAN backtrace in a bug using the mouse
2. hit control-t
3. type bookmark keyword and space, ex: "sf "
4. paste the file path with colon
5. hit enter

We could potentially do better with a webextension that adds an option to your right-click menu, or even a web extension that recognizes what looks like backtraces in bugzilla and gives you code excerpts around all the frames in the backtrace that you can directly click into, etc. Especially as stack-traces fundamentally can bit-rot, but if the webextension extracts a date-stamp (or explicit revision) from the comment it can help searchfox rewind to the appropriate revision.

If implementing this directly, we'd want something like the define redirect in router.py but probably as specialized logic in the [default handler case]. It might be appropriate for parse_search to potentially use a heuristic to recognize that the ":NNN" is basically a suffix on a path-like thing rather than potentially interpreting the path as a key. (ex: if we go with :kats' https://github.com/staktrace/query-parser we would want to avoid that being confused).

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

In this case, I was copying the the line out of a crash report posted by a fuzzer; I wanted to see what the code looked like in that neighbourhood -- so you've pretty much nailed the use case on the head!

Comment 4

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

Another possibility in this general space is to add a new "endpoint" that takes URLs like:

• a crash-stats URL
• a treeherder summarized log or treeherder job which implies a log
• a bugzilla comment link which implies the textual contents of the comment

When pointed at these (and able to access the contents of the URL; no sec-bugs!), searchfox could scrape the text and apply heuristics based on both known context formats for the URL as well as a list of best-effort heuristics like recognizing different stack formats. A particularly nice thing from the URL approach is that it makes it more likely that searchfox can figure out a specific source code revision so there's no problems caused by assuming the current HEAD. treeherder jobs and crash-status URLs in particular would have reliable source code revisions that could be determined[1], but a bugzilla scraping approach could certainly apply some heuristics and explicitly identify what revision it went with plus what revisions it also considered as possible, providing quick access links to reinterpret the contents.

1: A solvable complication is that searchfox is tree-centric and we wouldn't want to make this the user's problem, so the daemon handling the new "endpoint" would need to know enough about the other extant trees to know when it should redirect to another tree. Right now each daemon only knows about its own config and it consumes a derived version of the config, but it would not be particularly hard for it to know about the other trees.