81524 - UI freezes for long period while sidebar search results are generated and displayed.

Status: VERIFIED DUPLICATE of bug 77460

(SeaMonkey :: Search, defect)

Description

[chris hofmann]

several times in the past week I notice that the UI freezes up 
when I to a bugzilla query that generates a long list of bugs.

The first list of bugs gets blasted out to the screen and
is drawn pretty quickly but then the UI freeze kicks in
and I can't scroll or click on other windows until what looks
like the entire document layout happens. The test url above
generates the table of about 1100 0.9.2 bugs. After this completes,
I get UI reposivness back and can scroll down and click on windows.

I'm playing with today's build on the high speed network at
work and the problem doesn't seem quite as visable.  I need to
try this again at home on my dial up connection that might be
the key part in trying to reproduce, or recent checkin's might
have made the problem less visible.

Comment 1

[chris hofmann]

ok,  trying at home again I see where the problem is.
it is not a problem with layout in the content window.

what happen is that:
-I do the query for a bug list that generates 1100 item bug list.
-while the content window starts to draw the page ui remains reponsive
  I can scroll down the page as more of it becomes available for viewing.
-when the entire page is shown then the UI locks up.
  what is happening is that stinkin' sidebar is running its search
  to generate search results associated with the page.
-since bugzilla is the default search provider in the commercial builds
 still that search is fair intensive and generates a long result list.
-when the sidebar search pannel completes its update I get UI responsiveness
 back...


something tells me that this either won't be a problem at all
when we finally hook up the right search provider, or that this
will be a horrendous problem for all pages that generates lengthy
search results...

when do we expect to hook up the right search provider to the
sidebar search pannel..

who should own this bug...  vishy?  if so take this from waterson.

changing summary to reflect the real problem.

I'm going to put this on the 0.9.1 radar until we get the
sidebar search pannel hooked up to the right search provider
and make sure it doesn't hog UI cycles on several top sites...

Comment 2

[matt]

Chris,

1)I imagine this bug is because you are loading a tree widget that contains 1100 
entries.  The search panel is still a tree widget.   We should evaluate if we 
should rewrite this as an outliner.  There are issues with this because we use 
xul in the tree widget at the moment which the outliner does not allow.  All of 
our default search engines only produce about 10 items per a page so usually it 
is not a problem.

2)Bugzilla will not be included in the commericial builds.  I'm adding the 
search providers as soon Bug 4936. Mozilla will continue to ship with bugzilla 
so it will contunue to be a problem if you run mozilla.

3) Actually Netscape is your default in both mozilla and commercial.  You can 
change your default to another provider in the prefs.  If you seach from a 
website that you have a sherlock file it will populate the sidebar. If this is a 
problem i would delete the sherlock file in your searchplugins directory.

4)I think rjc designed it this way to specifically punish managers who create 
bug queries that generate massive amounts of bugs.  Stop doing that!  It makes 
my brain hurt.

5)I'm the one you should point your gun at.  Stepping in front of waterson to 
take the bullet....the bug's all mine.

changing component to search....

Comment 3

[timeless]

isn't this bug a dupe?

Comment 4

[Chris Waterson]

Thanks matt. FWIW, there may still be issues with the search datasource even 
_after_ we convert to outliner. Let me know.

Comment 5

[Cathleen]

see also bug 49539
when we try to make a large query, our memory usage goes exponential too.

Comment 6

[gary_Cope]

Just for the record I see this with View->Show/Hide->Sidebar disabled, my
Internet Search pref to "open search tab in sidebar from search results.."
disabled, and my default search engine selected as lxr.

ie Im not remotely interested in any results being displayed in sidebar and
mozilla is hanging for minutes after it appears to have downloaded all content
from a bugzilla search of approx 1000, seemingly waiting to do document layout.

Perhaps this is a dupe of bug 77460 ?

Comment 7

[gary_Cope]

In addition to the above removing bugzilla.src from the searchplugins(as
mentioned in bug 77460) was a useful workaround, but not of much use if you want
the bugzilla search results displayed in sidebar.

Comment 8

[Cathleen]

see news posting...

news://news.mozilla.org/3B140D48.50908%40aandtech.com

should we re-write seach panel using outliner?  or is there any other solution?

Comment 9

[Blake Ross]

--> me. matt, if you had specific plans for this feel free to take back.

Comment 10

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 77460 ***

Comment 11

[Claudius Gayle]

VERIFIED Dupe