585523 - Quicksearch: advanced shortcut "[" doesn't support ',' OR syntax (Summary or Whiteboard, multiple alternative search words)

Status: NEW

(Bugzilla :: Query/Bug List, defect, P4)

Description

[Daniel Veditz [:dveditz]]

The quicksearch "[" shortcut for "summary or whiteboard" takes the following string as a single search term, leaving no easy way to do OR queries.

Example:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=!crash%20summary%3Aprint%2Ccaps
  returns ~30 hits

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=!crash%20sw%3Aprint%2Ccaps
  returns 1 hit (also in other list)

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=!crash%20[print%2Ccaps
  Zarro Boogs

Additional info that might be relevant:

If I do a search on "summary:print|caps" (instead of the comma) it seems to be interpreted as "summary:print OR caps", that is "print" is searched in the summary, but caps is searched in all the default fields component, products, whiteboard, content.

If I search "[print|caps" it's searching the summary for "print|caps" and whiteboard for "print|caps" (like the comma case, finding Zarro Boogs). If I search for "[print OR caps" it -ALSO- is searching the whiteboard and summary for "print|caps" and not finding any. A search for "[print OR [caps" searches for "print|[caps" in the summary or whiteboard (note literal '[' in the search term).

A search on "!crash sum:print,caps OR sw:print,caps" seems to give me the results I want (but cumbersome for more complex queries).

A search on "!crash sum:print,caps OR [print,caps" is truly bizarre given the above. It did not search on the literal string "print,caps", it searched for keyword crashed AND summary print or summary caps (so far so good) and then searched all the default fields for "[print" and separately for "caps".

Not sure if this is just one bug or 3 or 4.

I'm assuming the new '[' shortcut is something we picked up from upstream bugzilla, but if it's BMO-specific please retarget the bug.

Comment 1

[Max Kanat-Alexander]

The "[" shortcut isn't new, and probably neither is the behavior you're describing.

I agree that this is a bug and should be fixed. Most likely, though, it will be fixed as some part of refactoring quicksearch (and search in general) to behave in a more predictable and correct manner.

Comment 2

[Daniel Veditz [:dveditz]]

So what's special about the '[' shortcut? "!key1,key2" seems to work just fine, for example. And it's not just that "!" is a single field synonym because ":prodcomp1,prodcomp2" searches two fields and also does the expected thing.

If the code is just bad to the bone then I'll have to live with it, but with tantalizingly similar cases that seem to work fine it's hard to believe the '[' operator can't just re-use or copy the working code.

Comment 3

[Max Kanat-Alexander]

Try also @, :, and #.

I see the problem in the code, it's the search operators being used. The comma operator is basically only working coincidentally with the ! operator.

!one|two also won't work.

Comment 4

[Daniel Veditz [:dveditz]]

Maybe I just never noticed them in the quicksearchhack documentation page (now gone, so I can't check) or maybe BMO didn't support them, but from my PoV "[" and "#" are "new" operators and they both fail.

The "old" operators '@', ':' and '!' work fine with the ',' OR syntax.

Comment 5

[Thomas D. (:thomas8)]

Daniel, official quicksearchhack documentation pages are linked from the question mark next to the quick search box in bmo's header:

https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html
https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html#advanced

Another one:
http://www.squarefree.com/bugzilla/quicksearch-help.html

It's clear from the documentation that this is a bug that should be fixed, as acknowledged by Max in comment 1.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Max Kanat-Alexander from comment #3)
> Try also @, :, and #.
> I see the problem in the code, it's the search operators being used. The
> comma operator is basically only working coincidentally with the ! operator.
> !one|two also won't work.

Max, it's good news that you identified the problem in the code (btw, could you post an mxr link?)...
That might make it easier to follow up on what you said in 2010:

(In reply to Max Kanat-Alexander from comment #1)
> I agree that this is a bug and should be fixed.

QuickSearch is the swiss knife of bugzilla searches.
Using [searchword  syntax to limit search to summary and whiteboard is a very fast and efficient way of searching, if not the fastest when there's reason to assume certain searchwords will be in the summary of all respective bugs.

Not being able to use [searchword1,searchword2 (OR syntax) is a pretty big loss of functionality for that type of highly efficient searching.
And the workarounds for such searches are much harder to type, and very easy to get wrong:

Trying to search for (searchword1 OR searchword2) in (summary OR whiteboard):

1) [searchword1,searchword2 -> fails (zarro bugs)
2) [searchword1|[searchword2 -> fails (zarro bugs)
3) [searchword1 OR [searchword2 -> fails (zarro bugs)

4) [searchword1|searchword2 -> fails (zarro bugs); should be same as 6) below
5) [searchword1 OR searchword2 -> fails (zarro bugs); should be same as 6) below
6) summary:searchword1 OR searchword2 -> returns (summary:searchword1 OR anywhere:searchword2), which is technically correct, but it's not the intended search

7) summary:searchword1 OR summary:searchword2 -> returns summary:(searchword1 OR searchword2) - that's the intended search, but still without whiteboard!

8) summary:searchword1 OR summary:searchword2 OR whiteboard:searchword1 OR whiteboard:searchword2 -> that's the *only* workaround to produce *exactly same results* as the intended search, for which the search term according to documentation could be as simple as:

1) [searchword1,searchword2

Given that most possible alternative or pseudo-alternative combinations fail, and that the working workarounds are really clumsy compared to the simple syntax for an important use case (summary search), this isn't minor.

OT: Documentation for logical OR syntax /within/ values (using comma as OR separator) should be much more prominent, currently it is very hidden away, and also lacking examples. For easy reference, it should additionally be included in the general section about OR syntax, too.

Comment 7

[Jesse Ruderman]

Thomas, have you tried "su,sw:word1,word2" for searching in the summary and whiteboard?  It works fine for me.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Jesse Ruderman from comment #7)
> Thomas, have you tried "su,sw:word1,word2" for searching in the summary and
> whiteboard?  It works fine for me.

Cool stuff :) Jesse, thanks for enlightening me about that much better workaround for one out of several failures mentioned in this bug. So clumsy search pattern 8) from comment 6 is no longer the only option for that. However, most users will never find that workaround because it's not fully discoverable from quicksearch documentation [1]:

There's no explanation that we can search *multiple fields* by separating them with comma. Add to that the somewhat covert documentation for searching *multiple values* using comma (and the advanced knowledge and courage needed to abbreviate fields), and it's kinda hard for users to get that search right as you did (while it's much easier to run into one of the many cases that fail, as listed in comment 6).

After all, advanced shortcuts like '[' are there for a reason and per Max' comment 1, this problem has been around for long enough time to be addressed. Given that per Max' comment 3, he has already found the problem in the code, I put much hope into Max that he might be able to fix this. Please... :)

[1] https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html

Comment 9

[Jesse Ruderman]

It is mentioned on http://www.squarefree.com/bugzilla/quicksearch-help.html, fwiw :)

Comment 10

[Thomas D. (:thomas8)]

(In reply to Jesse Ruderman from comment #9)
> It is mentioned on http://www.squarefree.com/bugzilla/quicksearch-help.html,
> fwiw :)

Sure, but that's not our official documentation, fwiw :)
The two documents together actually make a nice set...