Open Bug 426288 Opened 17 years ago Updated 2 years ago

Urgences-Santé site visual header does not display correctly

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

People

(Reporter: chadwickgab+mozilla, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: regression)

Attachments

(6 files, 1 obsolete file)

The Urgences-Santé website does not display correctly. A menu does not show and header image is displaced. Just browse to http://www.urgences-sante.qc.ca/ and look at page. With Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9pre) Gecko/2008033105 Minefield/3.0pre ID:2008033105 and beta4 on xp. Will be looking for regression range.
Flags: blocking1.9?
Attached file Testcase extracted from the website (obsolete) (deleted) —
This regressed on 20080129 and it was working on 20080128. Added a not minimized at all testcase in case they change the website. The files are missing since I can't add a zip the bugzilla...
Maybe related to bug 134706
Blocks: 134706
Clearing blocking flag... need a clearer testcase, I don't see anything wrong on the site itself.
Flags: blocking1.9?
Attached image Screenshot of wrong rendering (deleted) —
Testcase is not complete here is a link to complete testcase extracted to website http://www.sauvetageag.com/dev/bug426288_testcase.zip Please check screenshot for difference.
Flags: blocking1.9?
Attachment #312844 - Attachment is obsolete: true
After disscussion with people on irc confirming the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Viewing the site, I can see the problem as well. +'ing w/ P2. Dbaron or roc, please feel free to adjust.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached file Testcase from comment 6 (deleted) —
So... The site has a <table width="742">. In one of the table cells, it has a left-aligned <table width="181"> followed by a <table width="550">. The left-aligned table contains an <img align="right" width="177"> in one cell, and an <img width="15"> in another cell in the same row. The second image is a spacer gif. The first image is aligned right, and we have a quirks.css rule that gives right-aligned images a 3px left margin. So the total width of this table is 177 + 3 + 15 = 195. This is greater than 181, so it's used as the width of the table. 195 + 550 = 745, which doesn't fit in the 742 pixels of space we have. So the second table wraps down. This used to work because we didn't wrap down tables even if they didn't fit... I really wonder what IE does here. If the outer table is changed to width="741", does IE wrap? If not, does IE not give images with align="right" a bit of left margin?
I'd love to hear what IE does here.
I'm more interested in what IE7 does if you change the 742 to a 741 in that testcase and then click the button. I'm also interested in whether IE7 leaves space to the left of a floated image when there's text flowing next to it.
(In reply to comment #13) > I'm more interested in what IE7 does if you change the 742 to a 741 in that > testcase and then click the button. Nothing happens, basically the screenshot remains as uploaded by Gabriel. > I'm also interested in whether IE7 leaves > space to the left of a floated image when there's text flowing next to it. Not really sure what you mean here. I put some text with your testcase and posted a screenshot of how IE7 renders it: http://martijn.martijn.googlepages.com/Clipboard02.gif I hope this helps.
Attached image Screenshot_IE7_OuterTableWidth_741 (deleted) —
IE7 on Windows XP display is the same varying the "Outer Table Width" from 1 to 741. At 742, I get a horizontal scrollbar because of my window width.
So IE just doesn't wrap down tables, even if they don't fit? What width does the outer table end up being in IE? > Not really sure what you mean here If you have something like: <img align="right">Text text text text .... with long text, and you resize the window, how close does the image get to the text befor we wrap the text more? In Gecko, we always leave a 3px space between the image and the text in quirks mode. What does IE do?
Testcase with offsetWidth values here: http://martijn.martijn.googlepages.com/test.html Screenshot of IE7 with outer table width set to 742 http://martijn.martijn.googlepages.com/Clipboard01.gif Screenshot of IE7 with outer table width set to 300 http://martijn.martijn.googlepages.com/Clipboard02.gif (In reply to comment #16) > If you have something like: > > <img align="right">Text text text text .... > > with long text, and you resize the window, how close does the image get to the > text befor we wrap the text more? In Gecko, we always leave a 3px space between > the image and the text in quirks mode. What does IE do? Yeah, I think I still see a 3px space between the image and text, and when I make the window then smaller, the text wraps. So there always seems to be a minimum 3px distance (ok, I don't know if it's 3px exactly, but something in the order of that).
So it sounds like IE has the "don't wrap a table that doesn't fit" bug that we fixed, and that this site is relying on it. :( I'm not sure what a good way is to fix this layout, to be honest. We could remove the 3px quirk, I suppose...
(In reply to comment #18) > So it sounds like IE has the "don't wrap a table that doesn't fit" bug that we > fixed, and that this site is relying on it. :( I don't think it does -- I think Safari also has that bug, but IE doesn't. See bug 134706 comment 28.
Hmm... I guess what it's really doing is ignoring the width attribute on the in-flow table and allowing it to wrap down to its intrinsic min width or something? The site has other images inside the in-flow table, so the testcase doesn't _quite_ mirror the site...
Do we have an idea of how many sites are affected by this? Is this a minor compat issue, or must we really block the release for this? Seems to me we are at a point where we gotta ship, and this looks like people are working around this already due to other browsers being inconsistent. I'm going to take a leap here, and go ahead and minus this. If people feel this is wrong, please re-nom.
Flags: blocking1.9+ → blocking1.9-
> Do we have an idea of how many sites are affected by this? Unknown. > Is this a minor compat issue, or must we really block the release for this? Probably unknown until we ship... I think if there is a simple fix we should just do it. Otherwise, it shouldn't block.
But I do think we need to figure out what the general plan here is and actually get it into the CSS spec...
Flags: wanted1.9.0.x?
Maybe the difference here is that IE's concept of min-width of blocks containing floats involves placing something next to the float? I don't think any other browser does that, though. (Gecko used to, but I think that was a while ago.)
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Might this be a duplicate of bug 425524?
Depends on: 425524
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Certainly looks like it to me.
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: