1772720 - Implement templating and UI hookup for pipeline-server and iterate a bit on the classic search experience as extant in the pipeline-server "query" mechanism

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

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

Bug 1761701 and friends gave us JSON search results from the pipeline-server from the built-up graph. The plan here is to:

• Translate those search results into HTML when the request doesn't have an Accept: application/json MIME type. (Also, maybe even if it does; accept can have quality scores that make things super complicated and axum's typed header support for this depends on https://github.com/hyperium/headers/issues/53 being implemented with more details at https://github.com/hyperium/headers/issues/7).
  • The plan is to directly produce semantic HTML rather than tunneling JSON through and converting it (which is what the existing "search" UI does).
• Alter the existing search header thing just for things produced by the pipeline-server to just be a single search field. Right now "search" has the separate case-sensitive, regexp search, and path filter affordances. The only one of these that couldn't already be handled via syntax in the search field is the case-sensitivity one, and the other two I think really hurt discoverability since you would assume the separate path filter box meant that the path: and pathre: options weren't available. But they absolutely are. More details at https://bugzilla.mozilla.org/show_bug.cgi?id=1762817#c0.
• Do some tweaking of crossref-expand, compile-results, and augment-results with added test coverage. I explicitly wrote a bunch of this new logic with addressing bug 1729164 and bug 1729371 in mind but the results I expected to see for nsIInputStream::Close when I ran it were not there, so that needs some iteration. Hopefully it's just trivial fixes at this point.

No changes will be made to any existing pages/templating at this time! Everywhere the existing search UI is found, it will continue to be found!

That said, it might end up that some new JS gets added to the existing JS files rather than a new JS file that only gets imported on the query page. I think it's probably a bit more likely that existing functionality could get broken by an inadvertent dependency on the new file that's only present in "query" contexts.

Comment 1

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

Attachment: Landed PR: Core templating support for query "search"-style results and diagramming

https://github.com/mozsearch/mozsearch/pull/529 has landed providing the scaffolding for "search" style results and diagrams, but both are effectively read-only; clicking does not do anything or what one would expect, and crossref-expand needs some more test coverage and fixes still, but the result is that the "query" mechanism will produce something you can look at on trunk.

Comment 2

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

Attachment: Landed PR: Add minimum limits for identifier search.

Limits were never put in place for the identifer-search which resulted in problems when running into the situation described in https://github.com/staktrace/query-parser/issues/3 which we may want to address.

Comment 3

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

Attachment: Landed PR: Graph traversal limits, metadata propagation including overloads hit