Closed
Bug 25879
Opened 26 years ago
Closed 26 years ago
Page not rendered correctly - mozilla pads tables
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: blockcipher, Assigned: troy)
References
()
Details
Attachments
(1 file)
|
382 bytes,
text/html
|
Details |
This page uses Javascript to detect browser type and it also uses tables, so I
left it here because I was unsure where the problem exactly lies. The text is
supposed to be next to the left-hand "border" of advertisements/links. My
original thought was that it was having problems with the tables, but after
looking at the code, it may be the javascript.
Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed
thru.
Assignee: nobody → leger
This page has literally hundreds of problems, not the least of which is that it
does explicit browser checking for IE3, IE4, Netscape3, and Netscape 4, and
mostly ignores the rest. If we simplify the case extremely, and treat it as if
the JavaScript thought that we are running IE4, we get the attached example:
A few things are happening here. First of all, we are relying on behaviour of
align="left" for non nested tables, the behavior of which is not well defined.
Second of all, if we remove align="left" from both tables, then both IE and
Mozilla render the two tables on top of each other. Finally, if you replace
all instances of width="610" with width="621" within table tags, then the
original page renders fine.
My first reaction was to say that zd is doing horrendous things on this page,
and we should ignore it. However, I realize that it does point out a
potentially important issue. Mozilla seems to treat tables with a width
attribute as approximately 4 pixels wider than the width attribute specifies
*even if border, cellspacing, and cellpadding are all set to zero*.
This is almost definitely a dup of bug 25617, albeit with very different
semantics
Assignee: leger → troy
Summary: Page not rendered correctly → Page not rendered correctly - mozilla pads tables - dup of 25617
Wow, tupshin, vert impressive job. You're right on about the additional 4px for
floated tables and yes that's the problem in 25617. I just notices that last
night. It's because of two rule in html.css that explcitly give a right-margin
for left floated tables and a left-margin for right floated tables
I'm working on fixing that now
Removing the bogus margins that are specified in html.css doesn't fix this case,
although it does fix bug #25617
Status: NEW → ASSIGNED
Summary: Page not rendered correctly - mozilla pads tables - dup of 25617 → Page not rendered correctly - mozilla pads tables
Marking as a DUP of 24795
*** This bug has been marked as a duplicate of 24795 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
Comment 7•26 years ago
|
||
*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com)
on 121 open or resolved (but not verified) bugs. sorry for the spam everybody,
but most of these bugs would just remain dormant and not checked by QA
otherwise. I'm not sure how so many bugs have nobody as their QA contact, but
I suspect this is the fault of some sort of bugzilla corruption that happened
at some point (most of these bugs are in the 20000-26000 range, and I don't see
where in the activity log that QA contact explicitly changed to
nobody@mozilla.org)
Anyways, sorry again for spam. If you really get annoyed, I'm usually
available in #mozilla on IRC for torture.
QA Contact: nobody → BlakeR1234
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•