304080 - The menustructure of the page is displayed badly

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Martin Domke]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050809 Camino/0.9a2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050809 Camino/0.9a2+

I tried to open this page with Safari and Firefox for Mac OS X. In both cases it
was working correctly. The menu structure should be in that way, that the
subentries are aligned from left to right.

Reproducible: Always

Steps to Reproduce:
1.You only have to open the indicated URL
2.
3.

Comment 1

[Samuel Sidler (old account; do not CC)]

Which build of Firefox did you try? Please try the latest nightly of Deer Park
(from 8/9) and see if the problem exists in Firefox. We share this code, so it's
very likely it does.

Also, don't approve for 0.9 without asking one of the devs.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Happens in DeerPark, too.

-> Core

Comment 3

[Samuel Sidler (old account; do not CC)]

Attachment: Reduced Demo

Here is a reduced demo showing our current behavior.

Comment 4

[Boris Zbarsky [:bzbarsky]]

That's still pretty big.  What's the minimal testcase that shows a behavior difference?

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase2, more minimised

This shows also the difference between Mozilla1.7 and current builds.
Apparently in current builds, absolute positioned child elements wrap inside relative positioned containers. 
This is also what Opera9 is doing, so that might very well be correct behavior (although the green bordered box should be placed right next to the red bordered box in Mozilla, not above it)

Comment 6

[Boris Zbarsky [:bzbarsky]]

The layout of that last testcase is correct per the CSS2.1 specification.  The relevant part of the specification is 10.3.7 <http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width>.  Let's go through that together:

  If all three of 'left', 'width', and 'right' are 'auto': First set any 'auto'
  values for 'margin-left' and 'margin-right' to 0. Then, if the 'direction'
  property of the containing block is 'ltr' set 'left' to the static position
  and apply rule number three below; otherwise, set 'right' to the static
  position and apply rule number one below.

This is the case we're in -- all three are 'auto', and 'direction' is 'ltr'.  Rule number three is:

  3. 'width' and 'right' are 'auto' and 'left' is not 'auto', then the width is
     shrink-to-fit . Then solve for 'right'

Going right along:

  Calculation of the shrink-to-fit width is similar to calculating the width of
  a table cell using the automatic table layout algorithm. Roughly: calculate
  the preferred width by formatting the content without breaking lines other
  than where explicit line breaks occur, and also calculate the preferred
  minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not
  define the exact algorithm. Thirdly, calculate the available width: this is
  found by solving for 'width' after setting 'left' (in case 1) or 'right' (in
  case 3) to 0.

  Then the shrink-to-fit width is: min(max(preferred minimum width, available
  width), preferred width).

In this case, the preferred minimum width is the length of the longest word (we try all possible line breaks).  The available width is the width of the containing block (since we have zero padding/margin/border).  The preferred width is putting everything on a single line.  So in our case we have:

preferred width > available width > preferred minimum width.

In this situation, the formula above gives the available width, which is exactly what we use.

If Safari's "preferred minimum width" is just the width with no line breaks, I can see it ending up with the behavior described in the demo from comment 3.  But that's not really something we want to be doing.

Comment 7

[Martijn Wargers (dead)]

Thanks for the explanation, Boris, but what about this statement I made:
"(although the green bordered box should be placed right next to the red
bordered box in Mozilla, not above it)".
Is that a correct statement, or not?

Comment 8

[Boris Zbarsky [:bzbarsky]]

If I understand what you mean correctly, that is bug 255139.