Closed
Bug 300816
Opened 19 years ago
Closed 19 years ago
mlb.com - menu dividers are in the wrong place (inline abs pos containing block)
Categories
(Core :: Layout: Positioned, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: joe, Assigned: bzbarsky)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
481 bytes,
text/html
|
Details | |
7.61 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
I and Steve England have noticed this. See bug 300685, comment #1. Bug 300685 is unrelated to this bug.
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•19 years ago
|
||
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•19 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
Comment 3•19 years ago
|
||
Ok, this regressed between 2004-04-24 and 2004-04-26. Probably the fix for bug 135082 caused this regression.
Blocks: 135082
Assignee | ||
Comment 4•19 years ago
|
||
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•19 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•19 years ago
|
||
please renominate if we decide that we'd rather be wrong.
Flags: blocking1.8b4? → blocking1.8b4-
Assignee | ||
Comment 6•19 years ago
|
||
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?
Assignee | ||
Comment 7•19 years ago
|
||
This makes us use the padding edge as the CB here, per the WG decision.
Assignee | ||
Updated•19 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+
Assignee | ||
Comment 9•19 years ago
|
||
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•19 years ago
|
Attachment #190334 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Updated•19 years ago
|
Assignee: nobody → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Assignee | ||
Comment 10•19 years ago
|
||
Fixed, with the change I mentioned in comment 9.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: blocking1.8b4?
You need to log in
before you can comment on or make changes to this bug.
Description
•