QuickSearch in Bugzilla 3 incorrectly searches the comment field by default. This causes two problems: * Many bugs are returned that shouldn't be returned. For example, "component:dom crash testcase" returns 10 bugs on bugzilla.mozilla.org and 70 bugs on bugzilla-test.mozilla.org. Comments like "this doesn't cause a crash", "moving all my non-crash bugs to M15", and "can you attach a reduced testcase?" make bugs show up incorrectly on that query. * Any search that does not include a field-constrained part, such as "add bookmark dialog,window", takes more than a minute and times out (bug 314364). From reading bug 70907 comment 155, I think this is just a bug rather than an intentional change. (It's also not documented on https://bugzilla-test.mozilla.org/page.cgi?id=quicksearch.html.) This makes it much harder to do useful searches with QuickSearch, and QuickSearch is currently the most efficient way to search for most things on bmo, so I think it should block deployment on bmo (bug 335151).

We either need to document this or change the behavior. If it does search comments, it should use the fulltext search instead of a substring search. That could be a convenient way to join QuickSearch and fulltext. (But that's another bug.)

It's the way QuickSearch worked all the time, so it's not a regression. I'm all for marking this one INVALID. You can set quicksearch_comment_cutoff to 0 if you don't want QuickSearch to search comments. You may document this, if you want to. On a related note, one of the biggest strengths of QuickSearch is its substring search. Don't take it away from me. Fulltext search not being able to search on stems is the reason why the Specific Search page is entirely not useful to me. (

> It's the way QuickSearch worked all the time, so it's not a regression. It's never worked that way on bugzilla.mozilla.org. You can compare the results of the search "component:dom crash testcase" yourself. Are you saying that bugzilla.mozilla.org made a configuration change to quicksearch.js and just needs to make the corresponding change to the server-side quicksearch in Bugzilla 3? If so, that's ok with me. > On a related note, one of the biggest strengths of QuickSearch is its substring > search. Don't take it away from me. Did you mean to say that in bug 335151? It seems off-topic here.

> It's never worked that way on bugzilla.mozilla.org. You can compare the > results of the search "component:dom crash testcase" yourself. Ok. That's because client-side QuickSearch defaulted its SearchLong option to false while the server-side QuickSearch's quicksearch_comment_cutoff parameter defaults to 4. > Are you saying that bugzilla.mozilla.org made a configuration change to > quicksearch.js and just needs to make the corresponding change to the > server-side quicksearch in Bugzilla 3? If so, that's ok with me. That's what I'm saying. > > On a related note, one of the biggest strengths of QuickSearch is its substring > > search. Don't take it away from me. > > Did you mean to say that in bug 335151? It seems off-topic here. I'm saying this in response to the last paragraph of comment 1.

wurblzap, this bug is invalid, right? If yes, then it should either be marked as an invalid Bugzilla bug, or moved to the mozilla.org product so that justdave doesn't forget to set the quicksearch_comment_cutoff param to 0. In both cases, please remove the blocking3.0+ flag.

I agree. Morphing, relocating and reassigning.

This has been done.