Last Comment Bug 300816 - mlb.com - menu dividers are in the wrong place (inline abs pos containing block)
: mlb.com - menu dividers are in the wrong place (inline abs pos containing block)
Status: RESOLVED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: x86 All
: P1 normal (vote)
: mozilla1.8beta4
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Jet Villegas (:jet)
Mentors:
http://toronto.bluejays.mlb.com/NASAp...
Depends on:
Blocks: 135082
  Show dependency treegraph
 
Reported: 2005-07-14 12:05 PDT by Joe Drew (not getting mail)
Modified: 2005-07-29 17:03 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (481 bytes, text/html)
2005-07-14 15:54 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
Proposed patch (7.61 KB, patch)
2005-07-24 14:12 PDT, Boris Zbarsky [:bz] (still a bit busy)
dbaron: review+
dbaron: superreview+
asa: approval1.8b4+
Details | Diff | Splinter Review

Description Joe Drew (not getting mail) 2005-07-14 12:05:14 PDT
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).
Comment 1 William Bumgarner [:zsinj] 2005-07-14 12:09:21 PDT
I and Steve England have noticed this. See bug 300685, comment #1. Bug 300685 is
unrelated to this bug.
Comment 2 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-07-14 15:54:38 PDT
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.
Comment 3 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-07-14 16:30:34 PDT
Ok, this regressed between 2004-04-24 and 2004-04-26. 
Probably the fix for bug 135082 caused this regression.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2005-07-14 21:44:01 PDT
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....
Comment 5 Asa Dotzler [:asa] 2005-07-22 14:26:26 PDT
please renominate if we decide that we'd rather be wrong.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2005-07-22 14:39:36 PDT
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...
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2005-07-24 14:12:16 PDT
Created attachment 190334 [details] [diff] [review]
Proposed patch

This makes us use the padding edge as the CB here, per the WG decision.
Comment 8 David Baron :dbaron: ⌚️UTC-8 2005-07-24 14:44:38 PDT
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?)
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2005-07-24 20:27:32 PDT
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/
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2005-07-25 15:18:13 PDT
Fixed, with the change I mentioned in comment 9.

Note You need to log in before you can comment on or make changes to this bug.