RESOLVED DUPLICATE of bug 45274 Bug 18090
static position of abspos element at the end of a single-line shrinkwrapped container is incorrect 
https://bugs.webkit.org/show_bug.cgi?id=18090
Summary static position of abspos element at the end of a single-line shrinkwrapped c...
jasneet
Reported 2008-03-25 16:43:49 PDT
I Steps: Go to http://skyrock.com/ II Issue: Text "powered by yahoo search" on top right near button "go" is showing on to next line. III Conclusion: Issue is caused due to position:absolute; Safari/FF/Opera/IE behave the same way on removing this property. IV Other browsers: IE7: ok FF3: ok Opera9.24: ok V Nightly tested: 31238
Attachments
screenshot (169.06 KB, image/jpeg)
2008-03-25 16:44 PDT, jasneet 		no flags
Details
reduction (627 bytes, text/html)
2008-03-25 16:45 PDT, jasneet 		no flags
Details
Reduction (537 bytes, text/html)
2012-07-18 15:12 PDT, Pravin D 		no flags
Details
Patch (7.97 KB, patch)
2012-12-12 11:38 PST, Robert Hogan 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
jasneet
Comment 1 2008-03-25 16:44:36 PDT
Created attachment 20057 [details] screenshot
jasneet
Comment 2 2008-03-25 16:45:38 PDT
Created attachment 20058 [details] reduction
Tab Atkins
Comment 3 2011-10-20 01:02:10 PDT
Yup, valid bug. The error is that, if an inline element is the last thing in a single-line shrinkwrapped container, when you position the inline its static position is instead computed as if it linewrapped onto a second line. Here's a testcase: <!DOCTYPE html> <div id=wrapper> <div id=inline></div><div id=inline-positioned></div> </div> <div id=cover></div> <style> body { margin: 0; } #wrapper { float: left; } #inline { display: inline-block; width: 50px; height: 20px; background: green; } #inline-positioned { display: inline-block; width: 50px; height: 20px; background: red; position: absolute; } #cover { position: absolute; top: 0; left: 50px; width: 50px; height: 20px; background: green; } </style>
Pravin D
Comment 4 2012-07-18 15:05:52 PDT
(In reply to comment #3) > Yup, valid bug. The error is that, if an inline element is the last thing in a single-line shrinkwrapped container, when you position the inline its static position is instead computed as if it linewrapped onto a second line. > > Here's a testcase: > > <!DOCTYPE html> > <div id=wrapper> > <div id=inline></div><div id=inline-positioned></div> > </div> > <div id=cover></div> > <style> > body { margin: 0; } > #wrapper { > float: left; > } > #inline { > display: inline-block; > width: 50px; > height: 20px; > background: green; > } > #inline-positioned { > display: inline-block; > width: 50px; > height: 20px; > background: red; > position: absolute; > } > #cover { > position: absolute; > top: 0; > left: 50px; > width: 50px; > height: 20px; > background: green; > } > </style> > The above test case is a little different from the one jasneet has reported. If you move the <style> stuff above the first <div> there will be no red box seen. Your test case exposes another bug , that for positioned objects the renderers are not properly re-attached. See https://bugs.webkit.org/show_bug.cgi?id=91665
Pravin D
Comment 5 2012-07-18 15:12:06 PDT
Created attachment 153098 [details] Reduction
Robert Hogan
Comment 6 2012-12-12 11:38:24 PST
Created attachment 179093 [details] Patch
Robert Hogan
Comment 7 2012-12-15 04:01:30 PST
*** This bug has been marked as a duplicate of bug 45274 ***
Robert Hogan
Comment 8 2012-12-15 04:02:43 PST
Here's the reduction without any collapsing space. It passes. data:text/html,<!DOCTYPE html><style>body { margin: 0; }#wrapper {float: left;}#inline {display: inline-block;width: 50px;height: 20px;background: green;}#inline-positioned {display: inline-block;width: 50px;height: 20px;background: red;position: absolute;}#cover {position: absolute;top: 0;left: 50px;width: 50px;height: 20px;background: green;}</style><div id=wrapper><div id=inline></div><div id=inline-positioned></div></div><div id=cover></div> So this the same issue as bug 45274.
Note You need to log in before you can comment on or make changes to this bug.