298716 - Search string prefix corresponding to any match function causes error

Status: RESOLVED WORKSFORME

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

Description

[Will Budreau]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Searching on comment or subject starting with the string "matches" fails miserably

Reproducible: Always

Steps to Reproduce:
1. Visit a bugzilla search page (including the enter_bug url above)
2. enter the string "Matches"
3. Click Search

Actual Results:  
Page returns:

Illegal Search
	  	
The "content" field can only be used with "matches" search and the "matches"
search can only be used with the "content" field.

Expected Results:  
Given me a list of results

Note this makes it moderately annoying to search for any existance of this bug
by searching on the string "matches" because I can't.

Here's the requested URL that showed the issue
https://bugzilla.mozilla.org/buglist.cgi?format=simple&order=relevance+desc&bug_status=__open__&product=Bugzilla&content=matches

Comment 1

[Ria Klaassen (not reading all bugmail)]

I see the same on that url.

Comment 2

[Frédéric Buclin]

joel, could you please investigate?

Comment 3

[Joel Peshkin]

Happens on tip too.  All you need to do is search for a summary of "matches blah" 

Comment 4

[Joel Peshkin]

This is probably pretty fundamental in Search.pm and has been around for a
while.  I'm suprised that it has gone this long undetected.

The function im Search.pm being triggered is this...

        ",matches" => sub {
             ThrowUserError("search_content_without_matches");
         },

So, I tried searching for a summary containign "lessthan" and got an sql error.

Comment 5

[Dave Townsend [:mossop]]

I believe I'm seeing a variant of this. Searching bugzilla for the summary
"regexp test" returns no bugs, but searching for "Regexp test" or "test regexp"
both return the same 5 bugs. This is with the summary search set to "contains
all of the words/strings"

Comment 6

[Joel Peshkin]

I think it is getting to be time for Search.pm to start to take a list of
arguments rather than playing with commas.  Naturally, there are many
implications of this so it will take a while.

Comment 7

[Frédéric Buclin]

Only security and dataloss fixes will be accepted on the 2.20 branch.

Comment 8

[timeless]

Attachment: trivial

Comment 9

[Joel Peshkin]

Comment on attachment 275395 [details] [diff] [review]
trivial

This breaks everything that does operations like....

            $funcsbykey{",$t"}->();

Comment 10

[timeless]

Attachment: 0 or more

Comment 11

[Teemu Mannermaa (:wicked)]

Comment on attachment 275647 [details] [diff] [review]
0 or more

I'm sorry but this is too badly bitrotten by bug 399371.

>Index: Bugzilla/Search.pm
>===================================================================
>-      my $deadlinefrom;
>+        my $deadlinefrom;

Please, there's no reason for doing indentation fixes in this same patch. This change is already complicated enough.

>@@ -422,6 +422,7 @@
>+    my $firstfield = '^[^,]*';

I'd say using this variable only complicates funcdefs more than it saves.

Does this need to be this complicated? Would using something like |^,matches| work for all "any field using this type" entries in funcdefs?

Comment 13

[Max Kanat-Alexander]

This is fixed with the death of funcdefs in Bugzilla 4.0.