Bug 18080

Summary: wrong layout as style overflow:hidden doesn't affect webkit
Product: WebKit Reporter: jasneet <jasneet>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: bfulgham, jasneet, tabatkins, webkit
Priority: P2 Keywords: HasReduction
Version: Safari 9   
Hardware: All   
OS: All   
URL: http://cn.msn.com/
Attachments:
Description Flags
screenshot
none
reduction none

jasneet
Reported 2008-03-25 14:43:23 PDT
I Steps: Go to http://cn.msn.com/ Scroll to the end of the page. II Issue: The search bar at the bottom of the page has wrong layout. It is shifted upwards III Conclusion: On removing div style overflow:hidden, FF/Opera behave same as Safari. IV Other browsers: IE7: ok FF3: ok Opera9.24: ok V Nightly tested: 31238
Attachments
screenshot (152.28 KB, image/jpeg)
2008-03-25 14:43 PDT, jasneet 		no flags
Details
reduction (351 bytes, text/html)
2008-03-25 14:44 PDT, jasneet 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
jasneet
Comment 1 2008-03-25 14:43:43 PDT
Created attachment 20042 [details] screenshot
jasneet
Comment 2 2008-03-25 14:44:21 PDT
Created attachment 20043 [details] reduction
Tab Atkins
Comment 3 2011-10-19 21:40:06 PDT
Yup, we're wrong here. We're allowing margins to collapse through a BFC established with "overflow:hidden", which is a violation of the spec. Here's a test case: <!DOCTYPE html> <div id=error></div> <div id=a> <div id=should-be-bfc></div> <div id=b></div> </div> <style> #a { height: 40px; margin-top: 20px; } #b { height: 20px; margin-top: 20px; background: green; } #should-be-bfc { overflow: hidden; } #error { height: 20px; width: 100%; background: red; position: absolute; top: 40px; z-index: -1; } body { margin: 0; } </style> If you change the "overflow:hidden" to "display:table" (another way to establish a BFC), you see the correct behavior (the red is hidden, because the green block is pushed further down by its margins).
Chris Rebert
Comment 4 2016-02-03 18:36:12 PST
Still reproduces in Safari Version 9.0.3 (11601.4.4) on OS X El Capitan. Looks like this was fixed in Chrome; it doesn't repro in Chrome 48.
Brent Fulgham
Comment 5 2022-07-11 16:19:06 PDT
Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.
Note You need to log in before you can comment on or make changes to this bug.