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.
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.
Ok, this regressed between 2004-04-24 and 2004-04-26. Probably the fix for bug 135082 caused this regression.
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....
please renominate if we decide that we'd rather be wrong.
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...
Created attachment 190334 [details] [diff] [review] Proposed patch This makes us use the padding edge as the CB here, per the WG decision.
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 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/
Fixed, with the change I mentioned in comment 9.