large blocks of table rows not rendered (missing) when colspan to non-existent column

RESOLVED WORKSFORME

Status

()

P2
blocker
RESOLVED WORKSFORME
16 years ago
10 years ago

People

(Reporter: mrmazda, Unassigned)

Tracking

({qawanted, testcase})

Trunk
Future
x86
All
qawanted, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(11 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
Set sort order to bug number ascending.

I've seen this occasionally for a long period of time, probably at least six
months. However, yesterday in 2003032612 OS/2 trunk it became very difficult to
find the most recently filed bugs, and today in 2003032712 is no better. Reload
page usually doesn't help. Clearing cache usually doesn't help. If the browser
is freshly opened, the two may match, but reloads far more often than not fail
to increase the last message number displayed to the vicinity of the actual last
message reported.

e.g.
I just hit reload in W98 (2003032208) at the same time as hitting reload in OS/2
(2003032712). Both claimed 134 bugs found. W98's last message displayed was
199568, while OS/2's was 199531.

Comment 1

16 years ago
this sounds like a necko problem
(Reporter)

Comment 2

16 years ago
60 minutes later, 5 consecutive reloads produced 139 total, but still 199531
OS/2 last, while last incremented to 199574 on W98.
(Reporter)

Comment 3

16 years ago
Tried 'em both again. OS/2=199532 & 160. W32=199600 & 160.
(Reporter)

Comment 4

16 years ago
No improvement today in OS/2 2003032812. Before starting Mozilla, I deleted
cookies.txt. When both OS/2 & W2 reported only 95 bugs found, both displayed the
same last bug number, as it had several times earlier in the day with fewer
total bugs found. On next check, both reported 104 found, but W32 displayed last
number 199743, while OS/2 skipped 199739, 199740, 199742 & 199743, showing
199738 as last bug, which appears to be a listed bug total of exactly 100.
(Reporter)

Comment 5

16 years ago
Next reload: both reported total of 113. OS/2's last remained 199738 (still 100
total), while W32 increased to 199752.
(Reporter)

Comment 6

16 years ago
Created attachment 118856 [details]
Query result on W32 for open browser bugs - "assert" in summary

146 boogs found. 146 boogs listed. File size 84872.
(Reporter)

Comment 7

16 years ago
Created attachment 118857 [details]
Query result on OS/2 for open browser bugs - "assert" in summary

146 boogs found. 100 boogs listed. File size 166747. Why is this file twice the
size of W32 result file?
More than 100 bugs are listed in the OS/2 case. They just all have 100 by them...
(Reporter)

Comment 9

16 years ago
Created attachment 118860 [details]
Query result on OS/2 for open browser bugs - "assert" in summary

I added the item numbers 10 at a time to keep from messing up, refreshing
browser after each 10. I missed the fact that I hadn't reached EOF.

So, why does my OS/2 browser stop at #100 each time for the past three days,
and occasionally even before then? I dumped cookies before starting up
yesterday's build. I see that the obstacle appears to be the second instance of
column headers after #100. What's left to try? Do you have multiple query
result pages open at once as I do?
Attachment #118857 - Attachment is obsolete: true
(Reporter)

Comment 10

16 years ago
Created attachment 118862 [details]
Screenshot for disbelievers - same query on OS/2
what is this screen shot supposed to be showing?
(Reporter)

Comment 12

16 years ago
SS indicates result of query described in comment 6 & 7. When you run the query
with results displayed sorted on bug number, the last bug number displayed
should be 199508, not 155245.
(Reporter)

Comment 13

16 years ago
This test was run simultaneously on both PC's.
Search criteria: verified or resolved duplicate in
number of days indicated.
       OS/2     OS/2      W32      W32
       Boogs    Last     Boogs    Last
Days   Found  Displayed  Found  Displayed
   1      109   199716      109   199766
   2      186   199766      186   199766
   3      252   195228      252   199766
   4      327   199766      327   199766
   5      397   199766      397   199766
   6      468   199017      468   199766
   7      531   199602      531   199766
OK, let's try this test:

1) in both browsers, go to http://bugzilla.mozilla.org/query.cgi
2) IMPORTANT: set the sort order to "Bug Number" at the bottom of the query page
before you submit
3) Run your query
4) compare the results to see if they match
5) copy/paste the URL from the URL bar while viewing the results into this bug,
from BOTH browsers, so we can see them.  They should exactly match.  If they
don't, then you didn't select the same query from the query page.
6) If the results are still different on each, despite the URLs being identical,
then add &debug=1 on the end of the URL on both browsers and hit Enter.  This
should cause the actual SQL query that was run to be shown at the top of the
buglist.  Copy/paste that SQL from both browsers into this bug.
(Reporter)

Comment 16

16 years ago
While the without debug queries matched, these don't.

OS/2 query with debug:
SELECT bugs.bug_id, bugs.bug_severity, bugs.bug_status, bugs.resolution,
map_products.name, map_components.name, bugs.op_sys, bugs.votes, bugs.short_desc
FROM bugs, products AS map_products, components AS map_components LEFT JOIN
bug_group_map ON bug_group_map.bug_id = bugs.bug_id AND bug_group_map.group_id
NOT IN (9,10) LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 25030 WHERE
bugs.product_id = map_products.id AND bugs.component_id = map_components.id AND
(bugs.product_id IN (1)) AND (bugs.bug_status IN ('NEW','ASSIGNED','REOPENED'))
AND (INSTR(LOWER(bugs.short_desc), 'assert')) AND ((bug_group_map.group_id IS
NULL) OR (bugs.reporter_accessible = 1 AND bugs.reporter = 25030) OR
(bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR (bugs.assigned_to =
25030) OR (bugs.qa_contact = 25030) ) GROUP BY bugs.bug_id ORDER BY bugs.bug_id

W32 query with debug:
SELECT bugs.bug_id, bugs.bug_severity, bugs.bug_status, bugs.resolution,
map_products.name, bugs.op_sys, bugs.votes, bugs.short_desc FROM bugs, products
AS map_products LEFT JOIN bug_group_map ON bug_group_map.bug_id = bugs.bug_id
LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 77325 WHERE bugs.product_id
= map_products.id AND (bugs.product_id IN (1)) AND (bugs.bug_status IN
('NEW','ASSIGNED','REOPENED')) AND (INSTR(LOWER(bugs.short_desc), 'assert')) AND
((bug_group_map.group_id IS NULL) OR (bugs.reporter_accessible = 1 AND
bugs.reporter = 77325) OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR
(bugs.assigned_to = 77325) OR (bugs.qa_contact = 77325) ) GROUP BY bugs.bug_id
ORDER BY bugs.bug_id
(Reporter)

Comment 17

16 years ago
I now see that the component had been omitted from the W32 results display, but
that has no impact on the fact that OS/2 is cutting off the list after the 100th
listed bug.
(Reporter)

Comment 18

16 years ago
Clarified summary to be less restrictive per subsequent comments.

Dave, I'm on #mozilliazine now if you have more ideas.
Summary: # bugs found != # bugs displayed at "bugs already reported today" → # bugs found != # bugs displayed
You're also logged in as a different user in each browser.

It matters.  Please try the test again as the same user in each browser, just to
eliminate user permissions as a variable.
OK, based on discussion with Felix in IRC, this is definitely a browser bug.

When he does a view-source on the buglist on OS/2, the bugs are there in the
source, just not rendered when viewing the buglist.
Assignee: endico → table
Component: Query/Bug List → Layout: Tables
Product: Bugzilla → Browser
QA Contact: matty → madhur
Version: 2.17.1 → Trunk
(Reporter)

Comment 21

16 years ago
I just managed a one shot duplication of this on 2003032808 W32. I performed the
same queries as described in comment 13. Both returned 326 boogs found for 5
days, but the last # on W32 was 199875, while on 2003032113 OS/2 the last # was
199894. A reload of W32 included the missing last 8. Searches of 1, 2, 3, 4, 6,
& 7 produced identical results on each, all ending with 199894.
I was seeing this earlier, but now I am not seeing it at all.

I have tested on multiple builds (for the past two weeks)

No idea what to do with it.
(Reporter)

Comment 23

16 years ago
I just managed a one shot duplication of this on 2003040105 Linux. I performed
the same queries as described in comment 13. Both returned 280 boogs found for 4
days, but the last # on Linux was 199854, while on 2003032009 OS/2 the last #
was 200145. A reload of W32 included the missing last 8. Searches of 1, 2, 3, 5,
6, & 7 produced identical results on each, all ending with 200145.

OS -> All
OS: OS/2 → All
Summary: # bugs found != # bugs displayed → # bugs found occasionally != # bugs displayed
(Reporter)

Comment 24

16 years ago
Sloppy cut, paste & edit. :-P

s/A reload of W32 included the missing last 8./A reload of Linux included the
missing remainder./
(Reporter)

Comment 25

16 years ago
Upgrading severity to major. While it is possible to recreate in Linux and W32
(many tries to achieve one error), on OS/2 is very difficult to not achieve
error (many errors before achieving one success, typically 10 or more). Today I
have experienced several instances where the rendering omitted a first and/or
last table instead of just the last table, and one listed only one of the total
of 179 bugs (in 1.4a release 2003040120). Two bug query URL's where I repeatedly
see the bug are:

http://bugzilla.mozilla.org/buglist.cgi?email1=mrmazda%40ij.net&emailtype1=exact&emailreporter1=1

http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=mrmazda%40ij.net&emailtype1=exact&emailcc1=1&email2=&emailtype2=reg
Severity: normal → major
(Reporter)

Comment 26

16 years ago
Created attachment 119368 [details]
Testcase for upcoming screenshots
(Reporter)

Comment 27

16 years ago
Created attachment 119369 [details]
SS - how it should render, which OS/2 occasionally does
(Reporter)

Comment 28

16 years ago
Created attachment 119370 [details]
SS - how OS/2 usually renders
(Reporter)

Comment 29

16 years ago
Created attachment 119371 [details]
SS - how OS/2 occasionally renders #1
(Reporter)

Comment 30

16 years ago
Created attachment 119372 [details]
SS - how OS/2 occasionally renders #2
(Reporter)

Comment 31

16 years ago
This afternoon's screenshots courtesy of 1.4a release. I'm not sure how much
further I can reduce testcase, as the size of the table behaves as though part
or all of the problem. When I removed all but TH and 6 TD rows from the first
table, rendering was as expected for every reload.
Keywords: testcase
(Reporter)

Comment 32

16 years ago
Created attachment 119394 [details]
Reduced testcase (most of rows removed from first table)

Whether this renders correctly is quite random. Sometimes five straight or more
successes are possible, but just as likely five straight or more failures.
(Reporter)

Comment 33

16 years ago
Resummarizing to emphasize this is easy to reproduce in OS/2 and difficult on
Linux and W32.
Summary: # bugs found occasionally != # bugs displayed → OS/2 - # bugs found often != # bugs displayed - large blocks of table rows not rendered
(Reporter)

Comment 34

16 years ago
Created attachment 121246 [details]
SS showning most of two intermediate tables missing

Builds 2003042112 Linux and 2003042113 OS/2.

This OS/2 screenshot shows headers for the 2nd to last and  next to last tables
with no rows containing TD cells for either table rendered.  Linux rendered the
whole page, with #201671 the first and #202307 the last in the 2nd to last
table, and #202314 the first and #202827 the last in the next to last table.
The SS is from rerunning the test in comment 13 (except with Linux instead of
W32), the 7th and last of the queries. Of the 7 queries, Linux rendered
everything, while OS/2 rendered incompletely 4 of the 7.
(Reporter)

Comment 35

16 years ago
I discussed this a bit with bz on #mozilla. He said not being able to use
Bugzilla constitutes blocking testing, so upping severity accordingly.
Severity: major → blocker
(Reporter)

Comment 36

16 years ago
Tested again OS/2 trunk 2003042512. 287 bugs found. 100 bugs listed. Only first
table displayed completely. Column headers only for tables 2 & 3.
Summary: OS/2 - # bugs found often != # bugs displayed - large blocks of table rows not rendered → OS/2 blocker - # bugs found often != # bugs displayed - large blocks of table rows not rendered
(Reporter)

Comment 37

16 years ago
I found two "fixes" to this bug:

1-choose 'normal headers' instead of 'stagger headers' for bug queries.

2-remove 'colspan=2' from the 'full summary' column <th>, since there is no
second column for it to span.

1 is easy enough, but I prefer staggered for maximum compactness. For 2, I
simply saved a couple large buglists to disk, and removed colspan=2 from each
incidence of <th> for 'Summary'. On repeated reloads, the edited buglists
display fully every time, unlike the originals.
Summary: OS/2 blocker - # bugs found often != # bugs displayed - large blocks of table rows not rendered → large blocks of table rows not rendered when colspan to non-existent column

Comment 38

16 years ago
does the patch in bug 193257 ease the pain?
(Reporter)

Comment 39

16 years ago
No way for me to answer comment 38. I'm not equipped to build. However, that bug
was filed long before this behavior became routine, sometime between 20 March
and the date I filed this bug, most likely 25th, 26th, or 27th.
Priority: -- → P2
Target Milestone: --- → Future
(Reporter)

Comment 41

16 years ago
Still present in Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5a) Gecko/20030723
FWIW, this has happened to me a couple of times on Linux as well.
I remember looking in view-source and seeing that the content was actually there.
Reload "fixed" it.
(Reporter)

Comment 43

16 years ago
As I indicated in comment 23, I saw this once on Linux too (at that point). Much
easier to repro on OS/2, though. mkaply told me on moznet he thinks this is a
timing related and hardware dependant problem.

Mats, what is your hardware? Pre-Athlon AMD?
Dell Dimension, PIII 733 MHz, 256MB RAM

To me, it seems more likely it is related to that strange multi-part content
Bugzilla is sending.  I regurarly see my bug lists being loaded twice (which
is bug 137936) and I think this problem might be related to that somehow.
(Reporter)

Comment 45

16 years ago
Reload is no help on Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5b)
Gecko/20030825. Problem is as bad as ever.
(Reporter)

Comment 46

15 years ago
A while back I found a workaround for this behavior: change bug list column
selections so that there was an even number of headings, eliminating the colspan
to a non-existent column, allowing staggered header reports to render
completely. Within the past few days, this workaround stopped working.

2003112308 OS/2 trunk

Comment 47

15 years ago
I use WinXP and I see this bug often when loading long bug lists (~1000 bugs,
about 40% repro).  I've been seeing this bug for a long time.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
Firebird/0.7+

Comment 48

15 years ago
WFM?  I haven't seen this bug for about a month.
(Reporter)

Comment 49

15 years ago
Definitely not fixed in OS/2 1.6. In the OS/2 trunk, it is better, but still
broken. I've not been routinely using the staggered format due to this bug.

First several smaller bug lists with stagger after comment 48 I didn't see it. I
then saw it doing all resolved/verified duplicate in past 15d, 800+ bugs, and
past 11d, 660 bugs, but not in past 30d, 1500+ bugs, nor in past 22d, 1100+
bugs, nor in past 13d, 700+ bugs, nor past 18d, 900+ bugs, nor past 9d, 561 bugs.

If no one can repro this except on OS/2, maybe it needs WFM in other platforms
in status whiteboard, and moved back to OS/2 only.
(Reporter)

Comment 50

15 years ago
I began using my new Celeron 2400 yesterday morning. The Celeron is equipped
with a HD cloned from my old K6/3. I just used both to run Bugzilla queries:

verified or resolved duplicate in recent days: 2, 4, 6, 8, 10, 12, 15, 20, 25

The Celeron rendered all correctly. The K6/3 reproduced this on the 10 & 25 day
queries. I'm going to try installing the K6/3 HD in at least two other "slow"
machines when I get a chance, one with the same VIA MVP3 motherboard chipset
(FIC-503+), and another one at least with some other chipset (Intel and/or SiS),
all at 550 MHz or less.
(Reporter)

Comment 51

14 years ago
Not so easy to repro as it used to be, but still possible. On OS/2 both current
trunk and 1.7b on two different machines, resolved or verified duplicate in past
25 days failed on both, each at different bug numbers, while 1.7.3 afterward on
the slower box did fine.
This bug occured several times for me today, when this happens there are a few
rows displayed but most are missing. I see them all in "View Source" though.
Also, "select all" does not highlight the visible rows. (2005-01-22-05 Linux)
Summary: large blocks of table rows not rendered when colspan to non-existent column → large blocks of table rows not rendered (missing) when colspan to non-existent column
(Reporter)

Comment 53

14 years ago
OS/2 trunk 2005060115

I finally got to try that FIC-503+ system referred to in comment 50 using a
clone partition from the system used when this bug was originally filed, with
256M RAM and K6/2-450 and same video card. A search for verified or resolved
duplicate in last 15 days left out the 100 bugs beginning with 296045 and ending
with 296634 in between 269043 and 296641. However, with my even newer P4 2.8G
system and eCS 1.1 FP4 I was able to repro the exact same bad result. Both were
with 9 staggered columns: #, last changed, severity, status, resolution,
product, component, OS, full summary. I then tried the same thing on the
original machine I was using when I filed the bug, with the 2005060115 OS/2
trunk build, and the current linux gtk1 trunk, but they both worked correctly.
This bug needs a minimal testcase....
Keywords: qawanted

Comment 55

10 years ago
is this still an issue?

Comment 56

10 years ago
Please reopen if you have evidence that this is happening with a recent trunk build.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.