578815 - Searching "commenter" "contains the string" is very slow on large installations

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Neville Hillyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: 3.6.1

As far as I can tell it is almost impossible to efficiently search for 'all my posts' or 'all the bugs I have originated or commented upon'.

I have tried various Buzilla search facilities and cannot find an equivalent of the MozillaZine 'View your posts'. The best I can find is:

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&order=Last%20Changed&emaillongdesc1=1&email1=hillyer&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=EXPIRED&resolution=MOVED&emailtype1=substring

At the time of writing this finds 20 bugs (before this one). I think there should be a few more. It takes a long time (over 5 minutes at the time of writing) and frequently times out on non-Mozilla browsers such as Safari.



Reproducible: Always

Steps to Reproduce:
Use above long URL with Safari or other non-Mozilla browsers.


Expected Results:  
Bugzilla would be much more user friendly if users could find all of their past contributions within 10 seconds as they can with many large very busy forums.

My past email addresses have always included my surname and fortunately the email search appears to (correctly) ignore case.

Such a search may be impractical for many people.

I discovered that most advanced search sections could be left blank except 'Resolution' which, apparently, needs all categories highlighted for maximum hits - not user friendly.

I have been told that there were Buzilla server problems earlier today which may explain the five minutes but even on a good day it can still take about a minute.

Comment 1

[Max Kanat-Alexander]

Okay, so the bug here is that it's slow to do that search. I'm pretty sure that's already been filed.

Comment 2

[Frédéric Buclin]

If you use your full email address instead of a partial one, and use "is" instead of "contains", it takes less than 40 seconds to return the 21 bugs you commented in. The browser you use has nothing to do with the time spent to get your buglist.

Comment 3

[Neville Hillyer]

I have used several email addresses - they all contain Hillyer or hillyer but perhaps the latest email address should find them all.

The browser matters if the server, or its local network, are so slow that the time-out of a particular browser is exceeded as was the case most times earlier today.

At the time of writing (about midnight here) the following search took 63 seconds the first time and 29 seconds thereafter. I can't draw any conclusions from this but will try it from time to time. It would be better if it were faster but I can live with 29 seconds. Could we have a 'top level' 'my posts' link? Or at least a help file explaining how to do this search - it is not obvious and it takes several hours playing to get close to a satisfactory answer.

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&emailreporter1=1&order=Last%20Changed&emaillongdesc1=1&email1=n.hillyer%40open.ac.uk&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=EXPIRED&resolution=MOVED&emailtype1=exact

Comment 4

[Neville Hillyer]

It took 20 seconds today - this is OK for me so all I am asking for now is:

1 - A 'top level' 'my posts' link? - Perhaps based upon the above long URL.

2 - A help file explaining how to do this search if the 'top level' link cannot be provided.

Comment 5

[Max Kanat-Alexander]

Yeah, but 20 seconds is way too long for any search. Searches should ideally return in under a second.

It seems like there are two requests here:

1) Make commenter "contains" searches faster.
2) Make it easier to find bugs that I have commented on.

I actually consider #2 to be fairly easy already, and we've redesigned the Advanced Search page for 4.0 to hopefully make this even easier. I think that the number of people who want to do this on a frequent basis are probably actually somewhat of a small group, but they could make a saved search for it themselves if they wanted to.

So, that reduces the primary bug the #1, which I am changing the summary to reflect.

Comment 6

[Max Kanat-Alexander]

The request for the documentation is reasonable, though, by the way. We already have a bug for making documentation for common queries--if you can find it, add your suggestion there.

Comment 7

[Neville Hillyer]

It does appear that commenter includes reporter - can you confirm this? If not I am unhappy with your change.

Can the 'resolution' issue be fixed? In most other boxes no entry searches all but this does not work for resolution - difficult to use and not intuitive.

Comment 8

[Max Kanat-Alexander]

(In reply to comment #7)
> It does appear that commenter includes reporter - can you confirm this?

  Actually, it would, coincidentally, since the first comment is always from the reporter.

> Can the 'resolution' issue be fixed? In most other boxes no entry searches all
> but this does not work for resolution - difficult to use and not intuitive.

  It does work for resolution, actually. Perhaps you're selecting open statuses? In any case, if you're having some problem with the resolution field, our process would be to open a separate bug.

Comment 9

[Neville Hillyer]

Thanks for the 'commenter' information.

I cannot deselect everything in resolution. My tests indicate that the only way to overcome this is to highlight everything in the resolution box. This is unlike the other fields which default to all if nothing is selected. Resolution difficulties were part of my original bug report.

Comment 10

[Max Kanat-Alexander]

(In reply to comment #9)
> I cannot deselect everything in resolution.

  Ctrl-click.

Comment 11

[Neville Hillyer]

Ctrl-click does the same for me as just click - it selects the item under my curser - I don't recall ever being able to deselect everything in form multiple select fields. Normally forms provide a dummy line if this is required. I have tried the line indicated by hyphens but this does not appear to do the same as select all.

Comment 12

[Neville Hillyer]

I sort by bug number. How can I get it to automatically open with last bugs (higher numbers) first? Would it not be better to change the default action to this? - I am not so interested in 5 year old bugs!

Comment 13

[Max Kanat-Alexander]

Hey Neville. There are definitely answers to your questions, but they aren't really on the topic of this bug. The best thing to do would be to ask the support-bugzilla mailing list, described here:

  http://www.bugzilla.org/support/

Comment 14

[Neville Hillyer]

Which questions do you think they could answer?

Comment 15

[Neville Hillyer]

I got an email with the following and am surprised that a link bug 580208 was not put here:

 . . Bug 578815 depends on bug 580208, which changed state.

 . . Bug 580208 Summary: Search.pm: Combine all the user search types into one search function
 . . https://bugzilla.mozilla.org/show_bug.cgi?id=580208

Comment 16

[Max Kanat-Alexander]

(In reply to comment #15)
> I got an email with the following and am surprised that a link bug 580208 was
> not put here:

  Hey Neville. Thank you for your feedback. However, Bugzilla is not a general purpose support system, and comments are not the right place to report additional bugs. If you have an additional bug to report, then you should use the New Bug form, of course first searching to see if your bug has already been reported.

  It is also inappropriate to comment on multiple bugs with a comment unrelated to that bug.

Comment 17

[Neville Hillyer]

I don't understand.

Surely this is the correct place to say:

This bug depends on bug XYZ.