Closed Bug 60885 Opened 24 years ago Closed 19 years ago

Query results sometimes do not close html

Categories

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

2.10
x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: len, Unassigned)

References

()

Details

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-.
Keywords: 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
Depends on: 172120
Blocks: 172120
No longer depends on: 172120
I don't see the problem. Is this bug still valid?
Assignee: samir_bugzilla → query-and-buglist
No longer blocks: 172120
Component: Search → Query/Bug List
Product: Core → Bugzilla
QA Contact: claudius → default-qa
Version: Trunk → 2.10
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.