Closed
Bug 206516
Opened 21 years ago
Closed 18 years ago
change display property to none and block breaks table cell rendering
Categories
(Core :: Layout: Tables, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: osvaldo, Assigned: bernd_mozilla)
References
()
Details
(Keywords: testcase)
Attachments
(7 files, 3 obsolete files)
4.33 KB,
text/css
|
Details | |
973 bytes,
application/x-javascript
|
Details | |
4.87 KB,
text/html
|
Details | |
546 bytes,
text/html
|
Details | |
380 bytes,
text/html
|
Details | |
1.12 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
1.36 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030317 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030317 Try check/uncheck for many times the radioboxes in page: http://r2d2.rantac.com.br/ispman/bug.html and you will see the problem. Reproducible: Always Steps to Reproduce: 1. enter in http://r2d2.rantac.com.br/ispman/bug.html 2. check/uncheck radioboxes in page (many times) 3. done Actual Results: The page render crashes (table column) Expected Results: Disable/Enable table columns visibility.
Comment 1•21 years ago
|
||
The page is setting table elements (tr and td) to be display:block. We have some existing issues with this (not disposing of pseudo-frames properly), but even if those were fixed the page layout would still be "broken" (because CSS table display types are completely broken in IE and the page expects the IE behavior). Using table-row and table-cell for the display, as appropriate, will work in Mozilla and other CSS2-compliant browsers (but not in CSS1 browsers like IE/Windows). Over to tables to dup to the bug on pseudo-frame issues.
Assignee: dom_bugs → table
Component: DOM Style → Layout: Tables
QA Contact: ian → madhur
Whiteboard: DUPEME
Comment 2•21 years ago
|
||
checked the url on winXP and Linux on 2003-05-28trunk builds WFM! Osvaldo, please check this again in the latest build and if u do get a crash, provide the talkback crash id number or the stack signature.
Reporter | ||
Comment 4•21 years ago
|
||
Sorry for incovenience. The testcase has moved to: http://web.rantac.com.br/ab/bug.html
Osvaldo could you please attach the testcase to the bug just hit the Create a New Attachment link and follow the instruction. I suspect however that this bug is a dupe of 77019 which hopefully will be fixed in a near future
Depends on: 77019
Reporter | ||
Comment 6•21 years ago
|
||
Osvaldo, is your testcase just a html page? attach the html instead of the archive please. I can't open the archive.
Reporter | ||
Comment 8•21 years ago
|
||
Reporter | ||
Comment 9•21 years ago
|
||
Reporter | ||
Comment 10•21 years ago
|
||
Reporter | ||
Comment 11•21 years ago
|
||
the testcase is: 1 .html 1 .css 1 .js I will attach the 3 items separated...
Comment 12•21 years ago
|
||
Attachment #140618 -
Attachment is obsolete: true
Attachment #140740 -
Attachment is obsolete: true
Comment 13•21 years ago
|
||
Resummarizing to make it clear what the bug is about. Testcase never uses "visibility" and this has nothing to do with bug 77019
Comment 14•20 years ago
|
||
Comment 15•20 years ago
|
||
Windows XP and 2000, current Mozilla and Foxfire. I could not get a crash, but I get the described layout problems. Can we move this to confirmed? (attached another reproduction case)
Comment 16•20 years ago
|
||
We can't move it to confirmed, since it's a duplicate (at least the layout problems in your testcase are duplicates). Note the DUPEME keyword. Also note that even if the layout problems were fixed your testcase would still be "broken" because putting both of those cells in the first column when that "show" function runs is correct per the CSS spec.
Assignee | ||
Comment 17•19 years ago
|
||
Assignee | ||
Comment 18•19 years ago
|
||
This fixes a problem in block layout, but leaves the frame construction issue. The block problem is that the block caches the mAscent and if there are no lines inside the block the cached value is reported to the containing table cell.
Assignee: layout.tables → bernd_mozilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 19•19 years ago
|
||
Bernd, you want to spin that off into a separate bug, or check it in under this one?
Assignee | ||
Comment 20•19 years ago
|
||
Just the block reflow issue here and 162063 for the frame issue. The fix here will not complete give the space back as the remaining anonymous table cells will have their cellpadding cellspacing still applied.
Attachment #189538 -
Flags: superreview?(roc)
Attachment #189538 -
Flags: review?(roc)
Attachment #189538 -
Flags: superreview?(roc)
Attachment #189538 -
Flags: superreview+
Attachment #189538 -
Flags: review?(roc)
Attachment #189538 -
Flags: review+
Assignee | ||
Comment 21•19 years ago
|
||
fix checked in the reminder is bug 162063
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 22•19 years ago
|
||
Maybe this should be done on branch the patch seems to be simple (any regression) ? REOPEN ?
Flags: blocking1.8b5?
Flags: blocking1.8b4?
Comment 23•19 years ago
|
||
> Maybe this should be done on branch If you feel that way, request approval for the patch (see the flags on the patch itself) and explain in the approval request why this is needed and why it's very safe. > the patch seems to be simple (any regression) ? We probably won't know for at least a few weeks. Unless you have a source of knowledge I'm not aware of. > REOPEN ? Why? It's fixed. Whatever happens on branch doesn't affect the resolution, which tracks things on trunk. Not a branch blocker in any case, unless this is a very common problem out there. If it is, please point out the sites broken by it.
Flags: blocking1.8b5?
Flags: blocking1.8b5-
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Assignee | ||
Comment 24•19 years ago
|
||
The reduced testcase shows red again. As I did not checkin the test into the layout regression tests I can not pinpoint when this went bad again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 26•18 years ago
|
||
the regression in the reduced testcase has been fixed by the reflow branch
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Depends on: reflow-refactor
Flags: in-testsuite?
Resolution: --- → FIXED
Comment 27•17 years ago
|
||
These are based on the last testcase posted to this bug. I'm a bit concerned that this test will have to be marked as random, though. I've noticed that when I load the test, if I refresh the page quickly, I will sometimes see a very brief flash or red under the green cell. Depending on when the reftest takes the screenshot, that might pose a problem.
Attachment #257571 -
Flags: review?(dbaron)
Comment 28•17 years ago
|
||
Whoops, forgot to remove the table background color from the reference
Attachment #257571 -
Attachment is obsolete: true
Attachment #257572 -
Flags: review?(dbaron)
Attachment #257571 -
Flags: review?(dbaron)
Comment on attachment 257572 [details] [diff] [review] Reftests round 2 Checked in after testing in pre- and post-reflow-branch builds.
Attachment #257572 -
Flags: review?(dbaron) → review+
Updated•17 years ago
|
Status: RESOLVED → VERIFIED
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•