More often than not, the query results html is not completed -- it lacks the </body></html> tags. The results of this are that the page appears to be continuously loading, and search results don't get bunged into the search sidebar panel. This query reliably reproduces the problem for me: http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=MailNews&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=helpwanted&keywords_type=or&cmdtype=doit&newqueryname=&order=Bug+Number This is viewing under Mozilla 2000111919 Linux. If I view under ns4.7, the page finishes loading (throbber stops), however, view source reveals that there are still no closing body and html tags. Expected results: The above query should complete and the query results put into the search sidebar.
I'm not sure what happened, but this bug seems to have started off directly as NEW rather than UNCONFIRMED.
There's no UNCONFIRMED status in the Webtools product.
As far as I know, buglist.cgi never closes the body and html tags. I'm not having any trouble with the sidebar, though. The bugzilla cgi side of this problem is bug 47251.
Hmmm, you're right about it never closing the html -- I assumed that since some queries do finish loading and populate the search sidebar, that they had completed the html properly. Any ideas why some query results make it to the sidebar and others don't?
It's takes a few seconds on my computer (Win98/400mhz/128megsram) for the search sidebar to show the results, but they do show up correctly. Is this still a problem for you on more recent builds? (It might be linux-only..) Possibly related: bug 57357 Moving from webtools/bugzilla to browser/search.
Component: Bugzilla → Search
Product: Webtools → Browser
Yes, still a problem on Linux 2000112710.
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.
Sorry for the spam, I just wanted to follow knous's comment with a clarification. nsbeta1- keyword means that Netscape management has decided that it will not be able to contribute resources to fixing this for the next Netscape release. It does not mean that a fix for this would not be accepted. Normal r= and sr= checkin procedure still applies.
Tara is not a valid assignee for Browser/Search.
Thanks matt, forgot to hit "reassign bug to owner of selected component".
Assignee: tara → matt
QA Contact: matty → claudius
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
reassigning matt's old bugs to default owner.
Assignee: matt → sgehani
I don't see the problem. Is this bug still valid?
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.