Created attachment 52821 [details] Screenshot from Firefox Firefox 3.6.3 on Mac OS X 10.6.3.

Created attachment 52822 [details] Screenshot from Safari Safari 4.0.5 on Mac OS X 10.6.3.

<rdar://problem/7839788>

Reproduces in Safari 4.0.5 on Windows as well.

The issue appears to be due to differences between how Firefox (Gecko) and Safari (WebKit) do layouts when position:absolute is used, but top/bottom/left/right are not. In these cases, top/bottom/left/right are all set to "auto," so the browser is free to position such elements wherever it wants to. Firefox seems to place the element *to the right* of whatever came before it. Safari seems to place the element *below* whatever came before it (sometimes -- more on this later). StudentLoans.gov uses absolute positioning, but uses margins instead of top/bottom/left/right to set actual positions. The negative margin used to place the sign-in button is roughly equal to the width of the "main image" (with all the smiling people in it) plus the width of the "Manage My Direct Loan" image. In Firefox, this will currently work because the sign-in button is actually placed to the right of the main image. In Safari, because the sign-in button is on the line after the main image, moving it so far to the right moves it out of the window. I will attach a simplified example called "StudentLoans test" illustrating this. I'll need to do this as a ZIP file because of the necessary images. What's odd, though, is that Safari's automatic placement behavior is variable. I will attach two more examples (HTML only) illustrating this. The presence of whitespace between text and an absolutely positioned element affects automatic placement.

Created attachment 53210 [details] StudentLoans test

Created attachment 53211 [details] Simple example with whitespace

Created attachment 53212 [details] Simple example without whitespace

This is a dupe of bug 45274 to all intents and purposes. Can confirm once it lands.

Created attachment 198594 [details] Patch

Created attachment 198749 [details] Patch

Comment on attachment 198749 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=198749&action=review > LayoutTests/fast/inline/trailing-space-abspos-span.html:13 > + <!-- webkit.org/b/37245: The xxx and yyy should be all on the same line --> In my opinion, it is good to have a complete explanation in the test, and have it in the markup instead of in comments. When a test is failing, it makes it easier to just open it in Safari and directly see what is expected and how it is failing.

(In reply to comment #12) > (From update of attachment 198749 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=198749&action=review > > > LayoutTests/fast/inline/trailing-space-abspos-span.html:13 > > + <!-- webkit.org/b/37245: The xxx and yyy should be all on the same line --> > > In my opinion, it is good to have a complete explanation in the test, and have it in the markup instead of in comments. > > When a test is failing, it makes it easier to just open it in Safari and directly see what is expected and how it is failing. Me too. I'm testing the y-position of the line though and this would be affected by the height of the text above the line - which would differ from platform to platform. Could probably use line-height to fix that but didn't think too deeply and left it as a comment instead.

Created attachment 198939 [details] Patch

Comment on attachment 198939 [details] Patch Attachment 198939 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/159368 New failing tests: fast/inline/trailing-space-abspos-span.html

Created attachment 198941 [details] Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-12 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.2

Comment on attachment 198939 [details] Patch Attachment 198939 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/72860 New failing tests: fast/inline/trailing-space-abspos-span.html

Created attachment 198942 [details] Archive of layout-test-results from webkit-ews-07 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.2

Created attachment 198959 [details] Patch

Comment on attachment 198959 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=198959&action=review r- > Source/WebCore/rendering/RenderBlockLineLayout.cpp:3259 > + if (checkForBreak && !width.fitsOnLine(m_block->isFloatingOrOutOfFlowPositioned())) { Shouldn't it be all shrink to fit and not just floating or positioned? What about say inline blocks? > Source/WebCore/rendering/RenderBlockLineLayout.cpp:3297 > + if (width.fitsOnLine(m_block->isFloatingOrOutOfFlowPositioned()) || lastWS == NOWRAP) Same.

Created attachment 199091 [details] Patch

Comment on attachment 199091 [details] Patch Attachment 199091 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/16487 New failing tests: fast/inline/trailing-space-shrink-to-fit-parent.html fast/css-intrinsic-dimensions/css-tables.html fast/css-intrinsic-dimensions/tables.html

Created attachment 199103 [details] Archive of layout-test-results from webkit-ews-07 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.2

Created attachment 199111 [details] Patch

Comment on attachment 199111 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=199111&action=review > Source/WebCore/rendering/RenderBlockLineLayout.cpp:2742 > +static bool shrinksToFit(RenderObject* renderer) > +{ > + if (renderer->isFloatingOrOutOfFlowPositioned()) > + return true; > + > + EDisplay display = renderer->style()->display(); > + return display == INLINE_BLOCK || display == INLINE_TABLE || display == TABLE_CELL; > +} I am not understanding this patch at all. I don't get why shrink-to-fit should result in special behavior here. shrink-to-fit can be caused by any number of things, from a specified intrinsic width in CSS to default behavior for certain objects. That width can further be influenced by max/min-width to no longer be intrinsic, or maybe the container has a specified fixed width, etc. I need to understand more about what is going on here in order to understand why a behavioral change is needed only under certain circumstances. I'm unconvinced that shrink-to-fit is the right thing to be testing here.

Created attachment 199731 [details] Patch

Created attachment 200239 [details] Patch

Comment on attachment 200239 [details] Patch Attachment 200239 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/378117 New failing tests: fast/canvas/webgl/webgl-layer-update.html fast/block/positioning/relative-positioned-inline-container.html fast/forms/onselect-textarea.html fast/canvas/webgl/webgl-composite-modes.html media/audio-controls-rendering.html compositing/iframes/composited-iframe-alignment.html fast/forms/onselect-textfield.html fast/canvas/webgl/webgl-composite-modes-repaint.html

Created attachment 200248 [details] Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-12 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.2

Comment on attachment 200239 [details] Patch Attachment 200239 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/380144 New failing tests: fast/canvas/webgl/webgl-layer-update.html fast/block/positioning/relative-positioned-inline-container.html fast/forms/onselect-textarea.html fast/canvas/webgl/webgl-composite-modes.html media/audio-controls-rendering.html compositing/iframes/composited-iframe-alignment.html fast/forms/onselect-textfield.html fast/canvas/webgl/webgl-composite-modes-repaint.html

Created attachment 200294 [details] Archive of layout-test-results from webkit-ews-06 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.2

I am able to reproduce the issue from the test case (with whitespace) in Safari 15.5. While Chrome Canary 104 and Firefox Nightly 102 renders this similar to (without whitespace) output of Safari 15.5 on macOS 12.4. Thanks!

(In reply to Ahmad Saleem from comment #32) > I am able to reproduce the issue from the test case (with whitespace) in > Safari 15.5. While Chrome Canary 104 and Firefox Nightly 102 renders this > similar to (without whitespace) output of Safari 15.5 on macOS 12.4. Thanks! It seems that the failing (with whitespace) test case is also passing in STP161. @Alan - do we need to do anything else? Thanks!

(In reply to Ahmad Saleem from comment #33) > (In reply to Ahmad Saleem from comment #32) > > I am able to reproduce the issue from the test case (with whitespace) in > > Safari 15.5. While Chrome Canary 104 and Firefox Nightly 102 renders this > > similar to (without whitespace) output of Safari 15.5 on macOS 12.4. Thanks! > > It seems that the failing (with whitespace) test case is also passing in > STP161. > > @Alan - do we need to do anything else? Thanks! Thank you for testing, Ahmad! (this is an IFC progression)