Closed
Bug 14323
Opened 25 years ago
Closed 24 years ago
{compat} pages navigation tool bar isn't displayed properly
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
M17
People
(Reporter: ludo, Assigned: karnaze)
References
()
Details
(Keywords: testcase, Whiteboard: [TESTCASE])
Attachments
(7 files)
mozilla build is 1999091308.
I took it from the nighly/latest directory a few minutes ago.
This site displays job offering and you have to use some arrows to naviagte
from one to another. This arrows aren't displayed well under mozilla.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Comment 3•25 years ago
|
||
Updated•25 years ago
|
Assignee: don → karnaze
Component: Browser-General → HTMLTables
Whiteboard: [TESTCASE]
Comment 4•25 years ago
|
||
I think the bug here is that the navigation right-arrow is slipping down below
the left-arrow. On my NT4 box the text "13" is slipping down onto its own row
too, but that is caused by font-width variations between platforms/browsers
and is in my opinion not a bug (it occurs in NN 4.61, IE5 and Mozilla on NT4.)
Assignee | ||
Updated•25 years ago
|
Assignee: karnaze → kipp
Assignee | ||
Comment 5•25 years ago
|
||
Kipp, there was another bug with a nested table which exhibited very strange
behavior dealing with multiple images in a single <td> in which you gave 2 test
cases. I can't seem to find it, so there may be some duplication with my
comments here.
Nav 4.6 appears to be treating the max element size of a <td> containing
multiple images with no whitespace as the sum of the max element sizes of the
images. This is what is happening in attachment #3 [details] [diff] [review]. An even simpler example is
as follows. I cannot get Nav4.6 to split up the images in the 2nd cell no matter
what I change the table to be. And when I remove the width= on the table and
resize the window so it intersects the 2nd image, Nav 4.6 will not split up the
images either.
I think we need to treat the max element width of <td>s containing multiple
images with no whitespace between them as the sum of the max element widths of
the images. If there are contradictions to this (bug that I referred to
earlier), then we should just treat them as quirks we will not fix.
<HTML>
<HEAD>
<BASE HREF="http://dna.emploi.net/">
</HEAD>
<hr align=left style="width:150px;">
<table BGCOLOR="#F7D68C" width=150 BORDER=1 CELLPADDING=0 CELLSPACING=0>
<tr>
<td>xxxxxxxxxxxxxxxxx xxxxxx xxxxxx</td>
<TD><IMG SRC="icons/b_pre2.gif" WIDTH="21" HEIGHT="45"><IMG
SRC="icons/b_sui2.gif" WIDTH="21" HEIGHT="45"></TD>
</tr>
</table>
Well, the simplified test case now works...But a slightly different one doesn't.
Summary: pages navigation tool bar isn't displayed properly → {compat} pages navigation tool bar isn't displayed properly
More testing indicates that this is a compat mode quirk.
In particular, if you shrink down the word "page" to "p" it is laid out
properly. The fact is that the author didn't put in a "<nobr>" or "nowrap" for
the cell containing the two images, therefore we are allowed to break it.
That makes it a compat mode issue, which is probably a non-trivial thing to
validate that a pair of images next to each other act like a single image from a
max-element-size issue. I'll do some testing and see...
The following trivial tests that the max-element-size hack won't work. Try it in
nav4 and see...
<html>
<head>
<title>Test case for bug #14323</title>
<style>
</style>
</head>
<body>
<table cellspacing=0 border=0 cellpadding=0 width=199>
<tr>
<td><img
src=blue-square.gif width=100 height=10><img
src=blue-square.gif width=100 height=10></td>
</tr>
</table>
</body>
</html>
back to you chris...
Assignee | ||
Updated•25 years ago
|
Assignee: karnaze → kipp
Assignee | ||
Comment 10•25 years ago
|
||
Kipp, I think we need to do what I asked because (1) there appears to be more
cases and bugs needing it than not, (2) I cannot figure out what Nav is doing
for these cases and so cannot be 100% compatible with Nav and (3) IE5 does it
the way I asked (I guess MS couldn't figure out what Nav does either). I think
(3) is an important reason because doing it the way IE5 does it is better than
doing it a third way (ie. not Nav and not IE5). So, can you please implement
this and lets see what happens. I am in no position to do it, since I don't know
what is inside the block frame of the cell.
Assignee | ||
Comment 11•25 years ago
|
||
*** Bug 15544 has been marked as a duplicate of this bug. ***
Comment 12•25 years ago
|
||
Removing my name from CC list
Comment 13•25 years ago
|
||
*** Bug 16638 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
Comment 15•25 years ago
|
||
Ok, I have a new theory on how you should fix this bug. I suspect the
compatability issue can be solved by changing how your logic reserves space for
the borders. In particular, if you look at the "revised testcase showing (maybe)
..." you will see that the first 3 tables end up having the blue and green
images next to each other (subsitute your favorite image in place of mine...).
However, the fourth and later tables don't. I suspect navigator isn't reducing
the available table width by all of the border space necessary and consequently
the images fit. However, once the table width gets narrow enough, then they
don't fit and we see a difference.
I'm assigning this back to you to evaluate this potential solution.
Comment 16•25 years ago
|
||
Comment 17•25 years ago
|
||
Assignee | ||
Comment 18•25 years ago
|
||
Kipp, your last comments are interesting but a different bug (a bug in Nav that
I don't think we want to carry forward). The original bug attachment has no
border on the table. As an interesting side note, using your example, I found a
case where we don't wrap the images and Nav does!
<table width=23 cellspacing=0 cellpadding=0>
<tr>
<td><img src="blue-square.gif" width=2 height=2></td>
<td><img src="blue-square.gif" width=10 height=2><img
src="green-square.gif" width=10 height=2></td>
</tr>
</table>
Another interesting side note is that IE5 displays all of your examples with no
image wrapping, supporting my earlier claim that it treats the max element size
as the sum of image max element sizes.
I need to look at this some more.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M19 → M13
Comment 19•25 years ago
|
||
Resetting QA contact from leger.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M14
Assignee | ||
Comment 20•25 years ago
|
||
mass move to m14.
Comment 21•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 23•25 years ago
|
||
Build ID 2000042608 displays the pages correctly.
Comment 25•25 years ago
|
||
*** Bug 38382 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 26•24 years ago
|
||
*** This bug has been marked as a duplicate of 37656 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 27•24 years ago
|
||
Verified duplicate.
You need to log in
before you can comment on or make changes to this bug.
Description
•