Query results sometimes do not close html




Query/Bug List
18 years ago
13 years ago


(Reporter: Len Trigg, Unassigned)






18 years ago
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:


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.

Comment 1

18 years ago
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.

Comment 3

18 years ago
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.

Comment 4

18 years ago
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?

Comment 5

18 years ago
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

Comment 6

18 years ago
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-

Comment 8

18 years ago
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.

Comment 10

18 years ago
Thanks matt, forgot to hit "reassign bug to owner of selected component".
Assignee: tara → matt
QA Contact: matty → claudius

Comment 11

17 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future

Comment 12

17 years ago
reassigning matt's old bugs to default owner.
Assignee: matt → sgehani


16 years ago
Depends on: 172120


16 years ago
Blocks: 172120
No longer depends on: 172120

Comment 13

13 years ago
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


13 years ago
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.