Closed Bug 42755 Opened 24 years ago Closed 24 years ago

Mozilla only loads half a bug query

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: gabriel, Assigned: karnaze)

References

(
URL
)

Details

The URL above should show all open M17 bugs, instead it stops about halfway and
reports 'Document: Done'

I am currently using the M16 milestone release (2000061311), but I've also
noticed it with some of the recent nightlies.
Confirmed with 2000-06-16-11 on Linux. NN 4.x shows a long list but
mozilla stops before reaching the end. The last bug displayed is 22034.

Note: the list is so long (1125 bugs) that bugzilla inserts additional
headers (ID, Sev, Pri, etc...) in the list. Maybe it's a coincidence, but
mozilla stops rendering just before displaying the 4th header.

Adding 4xp keyword.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
tested with build 2000061708 on Win 98 SE
Allmost works on Windows. last bug listed is 35910 which is last bug on list 
using NN 4.72, but since the total isn't listed the only way to tell is to run 
the query on NN.
Tried two other tests. went to query page (default query) clicked on M17 and 
sort by bug number. same number of bugs, diferent sort. same result, all bugs 
listed but no total line. Next I just ran a querry for all open bugs sort by 
number. list ended at 15967. I think 2 or 3 bugs have been entered since bug 
15967 ;-) so that list isn't even complete.

OS should be updated to all
I don't see anything but a white page when loaded from mozilla on linux.
I see this too, win32. Marking so.

This is probably a dupe of those "long pages" bugs, but not sure. Bug 21637
looks like this. Any comments?
OS: Linux → All
Tested with build 2000061808 on Win 98
I ran a Bonsai querry, check-ins, sort by date, last month to generate a "long
page" from a different source. Mozilla passed this test. last entry was same in
Mozilla and NN 4.73. A dupe of bug 21673 should have had trouble with this page
since it's even longer than the M17 querry. I think the Bug's in Bugzilla.
Is it possible that this is a result of the fact that Bugzilla pages are
generated 'on-the-fly' ? In other words, while we are waiting for the next
'chunk' to be thrown out by Bugzilla, we mistakenly think we have reached the
end of the page ?

I just ran a m17 querry, Page loaded, throbber and progress meter stopped. I had 
the partial list. Checked with NN, last bug was same number, but still no total, 
no way of knowing if list was complete. I left it for 10 minutes to Gabriel's 
idea of a slow load. No change. Checked View page source. After page stops 
source is <p>Please stand by ... <p> (second tag is NOT a typo. It is not </p>). 
NN4.73 page source is a full HTML document. Saved NN 4.73 page to drive, Mozilla 
loaded it with no trouble.
While dowloading this NN paused a couple of times, then continued loading the 
page. Mozilla did not pause, it just stopped. Perhaps Bugzilla is sending the 
stand by while it generates more of the page. NN continues to load the page 
after the stand by, But Mozilla considers the page finished.
Work around - Fix enough M17 bugs, that Mozilla dosen't choke on long list ;-)
Could this be a regression related to bug 29305 ?

If you look at the bug I just mentioned, you will see that it actually turned
out to be a dupe of another one. If you look at that other bug, you will see
that Bugzilla sends a very long cookie (3888 bytes), and this cookie was what
was causing problems earlier. From John's comments about being able to load the
bug page from a file, I suspect that it is either this long cookie which is
causing problems again, or the transitional 'Please stand by' page.



adding dawn to cc: 
Personally, I think it was a cunning plan by Putterman so that he couldn't see
how many bugs he has ;-)
Just checked this again on Linux build 2000062914. The problem seems to be worse
now. The example page still only loads halfway, and after it has reported 'done'
the URL bar becomes empty, and it is impossible to focus on it.

tests with build 2000062920
Tested on 2 PCs today both 400 Mhz PII with Win98 SE
one pc had a 56k modem the other a 1.2M DSL connection.
PC with 1.2M DSL is same PC my earlier tests were made on.
Todays build is WFM on the fast connection. Earlier tests on this PC got all 
bugs but no total and footer.Works now that number of bugs is down to 1007.
PC with 56k dialup (actual connection speed 31.6k) failed, bad. didn't check url 
bar during test. PC that failed is at work, and I wont be running any more tests 
on it for 10 days (vacation :-)). 
Severity of problem dependant on connection speed?
gabriel, what connection speed are you testing this at?
I am using a 56K modem which connects at 33K.

over to HTML Tables
Assignee: asa → karnaze
Component: Browser-General → HTMLTables
QA Contact: doronr → desale
Status: NEW → ASSIGNED
Keywords: qawanted
Target Milestone: --- → M19
Seems to be fixed in Linux build 2000071108. Also tried it with M18 bugs, as
there are fewer M17 bugs now :-). Both pages load to the end.

Mark as wfm.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Please verify on other platforms.

Tested with Build 2000071810 on Win98
M17 (861 bugs) WFM
M17+M18 (2328 bugs) WFM
Unconfirmed + New + Assigned + Reopened (7837 bugs) WFM
Unconfirmed + New + Assigned + Reopened + Resolved + Verified (? bugs) That one 
froze Mozilla up, but NC 4.73 and IE 5.0 choked on it too.
Mozilla did beat IE :0)
WFM on Windoze with any reasonable number of bugs.
WFM with any reasonable number of bugs.
Verified with 2001-020608.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.