mlb.com - menu dividers are in the wrong place (inline abs pos containing block)

RESOLVED FIXED in mozilla1.8beta4

Status

()

Core
Layout: R & A Pos
P1
normal
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Joe Drew (not getting mail), Assigned: bz)

Tracking

({regression, testcase})

Trunk
mozilla1.8beta4
x86
All
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
This is related to
http://reporter.mozilla.org/app/report/?report_id=RMO11210914223764&submit_reportID=Lookup+Report
, but I'm not sure what the reporter <-> bugzilla method will be, so I'm
reporting it here too.

Since at least Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050710
Firefox/1.0+, and including Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3)
Gecko/20050714 Firefox/1.0+, the menu dividers on MLB pages (but it's especially
noticeable on bluejays.com) are being put in the wrong place.

I.e., usually you'd get Multimedia | News | Roster | ..., but now we're getting
something more like Multimedia   |News   |Roster (with the divider actually
overlapping the string slightly).
I and Steve England have noticed this. See bug 300685, comment #1. Bug 300685 is
unrelated to this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 189359 [details]
testcase

This is a minimal testcase based on that site.
I think this is a bug from Mozilla. Opera8 and IE6 seem to do this right.

This regressed between 2005-04-18 and 2005-04-28.

Updated

12 years ago
Component: General → Layout: R & A Pos
Keywords: regression, testcase
OS: Linux → All
Product: Firefox → Core
QA Contact: general → layout.r-and-a-pos
Ok, this regressed between 2004-04-24 and 2004-04-26. 
Probably the fix for bug 135082 caused this regression.
Blocks: 135082
Actually, I believe our layout here is absolutely correct.  The CSS spec says:

  If the element has 'position: absolute', the containing block is established
  by the nearest ancestor with a 'position' of 'absolute', 'relative' or
  'fixed', in the following way:
    # In the case that the ancestor is block-level, the containing block is
      formed by the padding edge of the ancestor.
    # In the case that the ancestor is inline-level, the containing block
      depends on the 'direction' property of the ancestor:
      1. If the 'direction' is 'ltr', the top and left of the containing block
         are the top and left content edges of the first box generated by the
         ancestor, and the bottom and right are the bottom and right content
         edges of the last box of the ancestor. 

Note that for a block-level ancestor the padding edge is used, while for an
inline-level ancestor, the content edge is used.  That's exactly what we're
doing.  We didn't use to do this right, and I made sure I fixed it in bug 135082.

On the other hand, given that IE 6 and Opera 8 both get this wrong, and given
that I am told that "Safari 2.0" also gets this wrong the same way, perhaps the
spec should just change.  :(

I'll raise this with the WG and hope they get back to me in time for 1.8....
Flags: blocking1.8b4?
(Assignee)

Updated

12 years ago
Summary: mlb.com - menu dividers are in the wrong place → mlb.com - menu dividers are in the wrong place (inline abs pos containing block)

Comment 5

12 years ago
please renominate if we decide that we'd rather be wrong.
Flags: blocking1.8b4? → blocking1.8b4-
Renominating.  I'm told that the WG is discussing this and should have a
decision by at most a week from now; I am also told there is a good chance
they'll just change the spec (which will make 1.7 right and our current code
wrong).  The fix to deal with that is very simple, so once I have the word I can
just do it...
Flags: blocking1.8b4- → blocking1.8b4?
Created attachment 190334 [details] [diff] [review]
Proposed patch

This makes us use the padding edge as the CB here, per the WG decision.
(Assignee)

Updated

12 years ago
Attachment #190334 - Flags: superreview?(dbaron)
Attachment #190334 - Flags: review?(dbaron)
Comment on attachment 190334 [details] [diff] [review]
Proposed patch

r+sr=dbaron, although the last of the chunks in nsHTMLReflowState is doing a
little more math than needed (or are all the methods involved inline?)
Attachment #190334 - Flags: superreview?(dbaron)
Attachment #190334 - Flags: superreview+
Attachment #190334 - Flags: review?(dbaron)
Attachment #190334 - Flags: review+
Comment on attachment 190334 [details] [diff] [review]
Proposed patch

Deflate() is not inline.  I'll switch to doing the math by hand before checkin
if I don't hear otherwise.

Fwiw, this patch passes the tests at
http://web.mit.edu/bzbarsky/www/testcases/containing-blocks/
Attachment #190334 - Flags: approval1.8b4?

Updated

12 years ago
Attachment #190334 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Updated

12 years ago
Assignee: nobody → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Fixed, with the change I mentioned in comment 9.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Flags: blocking1.8b4?
You need to log in before you can comment on or make changes to this bug.