Closed Bug 199569 Opened 22 years ago Closed 16 years ago

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

Categories

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

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

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: mrmazda, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, testcase)

Attachments

(11 files, 1 obsolete file)

Query result on W32 for open browser bugs - "assert" in summary
82.88 KB, text/html
Details
Query result on OS/2 for open browser bugs - "assert" in summary
162.84 KB, text/html
Details
Screenshot for disbelievers - same query on OS/2
21.60 KB, image/png
Details
Testcase for upcoming screenshots
105.21 KB, text/html
Details
SS - how it should render, which OS/2 occasionally does
18.83 KB, image/png
Details
SS - how OS/2 usually renders
17.63 KB, image/png
Details
SS - how OS/2 occasionally renders #1
16.90 KB, image/png
Details
SS - how OS/2 occasionally renders #2
17.83 KB, image/png
Details
Reduced testcase (most of rows removed from first table)
60.15 KB, text/html
Details
SS showning most of two intermediate tables missing
23.44 KB, image/png
Details
Unedited bug query results page (300K) (testcase)
298.93 KB, text/html
Details
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.
this sounds like a necko problem
60 minutes later, 5 consecutive reloads produced 139 total, but still 199531 OS/2 last, while last incremented to 199574 on W98.
Tried 'em both again. OS/2=199532 & 160. W32=199600 & 160.
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.
Next reload: both reported total of 113. OS/2's last remained 199738 (still 100 total), while W32 increased to 199752.
146 boogs found. 146 boogs listed. File size 84872.
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...
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
what is this screen shot supposed to be showing?
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.
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.
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
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.
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
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.
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
Sloppy cut, paste & edit. :-P s/A reload of W32 included the missing last 8./A reload of Linux included the missing remainder./
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
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
Whether this renders correctly is quite random. Sometimes five straight or more successes are possible, but just as likely five straight or more failures.
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
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.
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
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
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
does the patch in bug 193257 ease the pain?
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
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.
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.
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.
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
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+
WFM? I haven't seen this bug for about a month.
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.
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.
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
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
is this still an issue?
Please reopen if you have evidence that this is happening with a recent trunk build.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: