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)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 37656

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.
Attached image normal display using Netscape 4.6.1 (deleted) —
Attached image mozilla's buggy display (deleted) —
Attached file testcase (deleted) —
Assignee: don → karnaze
Component: Browser-General → HTMLTables
Whiteboard: [TESTCASE]
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: karnaze → kipp
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>
Status: NEW → ASSIGNED
Target Milestone: M17
Well, the simplified test case now works...But a slightly different one doesn't.
Attached file revised testcase that still fails (deleted) —
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...
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
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: karnaze → kipp
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.
*** Bug 15544 has been marked as a duplicate of this bug. ***
Removing my name from CC list
Status: NEW → ASSIGNED
Target Milestone: M17 → M19
*** Bug 16638 has been marked as a duplicate of this bug. ***
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
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.
Attached image first image for latest testcase (deleted) —
Attached image second image for latest testcase (deleted) —
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.
Status: NEW → ASSIGNED
Target Milestone: M19 → M13
Resetting QA contact from leger.
Target Milestone: M13 → M14
mass move to m14.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Moving to M16.
Target Milestone: M14 → M16
Build ID 2000042608 displays the pages correctly.
Moving to M17.
Target Milestone: M16 → M17
*** Bug 38382 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 37656 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Verified duplicate.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: