When only file / path results are returned, the 1000 result limit isn't mentioned, which can be confusing.
Categories
(Webtools :: Searchfox, defect)
Tracking
(Not tracked)
People
(Reporter: jwatt, Unassigned)
Details
I'd expect queries like:
https://searchfox.org/mozilla-central/search?q=&path=test**%2Fbrowser_&case=false®exp=false
https://searchfox.org/mozilla-central/search?q=&path=test*%2F**%2Fbrowser_&case=false®exp=false
to find the tests at:
https://searchfox.org/mozilla-central/source/devtools/client/aboutdebugging/test/browser/
|
||
Comment 1•2 years ago
•
|
||
It seems like we don't display the "Number of results: 1000 (maximum is 1000)" response boilerplate generated by search.js in the UI when the results are only path results. We do enforce a hard cap of 1000 results on the search_files result but it's separate from the other work_limit logic and we don't really signal that the limit is hit.
Although I'm re-titling the subject here to be about the absence of context on result counts and limits (which I think we need to fix), I expect there are probably reasonable use-cases where we shouldn't be forcing a hard limit of 1000. I think the 1000 limit in this case is mainly a UX assumption that no one would actually want 1000 results and that they'd refine their search after seeing way too many results, plus wanting to avoid janking the browser by feeding it a huge file in a way that prevents the user from refining their search. In the case of file results here, router.py actually has all the results because all we did was shell out to a grep, whereas semantic results are a situation where we might potentially need to perform a lot of marginal additional work beyond 1000.
:jwatt, is your motivating use-case one where you would like more than 1000 results? I know I personally do like to use ctrl-f after getting the file list results because the latency for changing the search result feels large enough that it's faster to control-f, and I wouldn't be surprised if others felt the same way!
|
Reporter | |
Comment 2•1 month ago
|
||
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #1)
Although I'm re-titling the subject here to be about the absence of context on result counts and limits (which I think we need to fix)
That seems to have been fixed BTW. The limit currently seems to be 4000.
:jwatt, is your motivating use-case one where you would like more than 1000 results? I know I personally do like to use ctrl-f after getting the file list results because the latency for changing the search result feels large enough that it's faster to control-f, and I wouldn't be surprised if others felt the same way!
Yes, I prefer that too. I also on occassion find that there is no good way to limit the search results returned, so prefer to get everything and filter things down a bit further using Firefox's Ctrl-f.
|
|
||
Comment 3•1 month ago
|
||
(In reply to Jonathan Watt [:jwatt] from comment #2)
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #1)
Although I'm re-titling the subject here to be about the absence of context on result counts and limits (which I think we need to fix)
That seems to have been fixed BTW. The limit currently seems to be 4000.
Yeah, I fixed that in https://github.com/mozsearch/mozsearch/commit/64d88b7da25799c459ebacbfdfb43c95d9ec3294 as part of bug 1459188 last year. Resolving WFM.
Description
•