Bug 10451 – Little icons in the wrong place on this blog

• Status: RESOLVED
• Resolution: INVALID
• Component: Layout and Rendering

[Dave Hyatt]

The 4 little icons in a column should be in the upper right, and instead they're sitting on top of the blog's content.  Opera and Firefox render this correctly.

This is not a regression... mis-renders in shipping Safari too.

[Mark Rowe (bdash)]

Created attachment 10083 [details]
Reduction

[Dave Hyatt]

Oh well, will keep this open, but it's pretty difficult to fix.  The error in omission of pixel units forces the absolute positioned div to size according to its intrinsic preferred width.  The layout inside is sufficiently complex that we cannot infer the correct width during the calcMinMaxWidth phase.

[Robert Hogan]

Created attachment 180942 [details]
Patch

[Dave Hyatt]

Comment on attachment 180942 [details]
Patch

This feels too much like a "one-off" hack just to fix this bug. I'm also not convinced it's totally safe to be calling startOffsetForLine at these times (when floats are in flux).

I can also change the test case to still fail.

[Robert Hogan]

(In reply to comment #4)
> (From update of attachment 180942 [details])
> This feels too much like a "one-off" hack just to fix this bug. 

The fix for https://bugs.webkit.org/show_bug.cgi?id=17103 is related to this one - so there's a few cases where the need to account for inlines avoiding floats arises when calculating the max width.

> I'm also not convinced it's totally safe to be calling startOffsetForLine at these times (when floats are in flux).

You mean when inserting the floats in clearFloats() ? If inserting a float causes the inline offset to change then the preferred logical widths always need to be recalculated afaict.

> 
> I can also change the test case to still fail.

I'm guessing similar to bug 17103, but yes - I'm probably guilty of sticking tooo narrowly to the problem in the reduction rather than opening it out to other ways this could fail.

[Dave Hyatt]

Just to elaborate, when you start looking at line offsets in preferred width computations, you're actually creating a dependency between a previous layout (or what you're doing in the current layout) and the preferred width computation. Basically you no longer have a self-contained algorithm in preferred width computations that is separate from layout and instead have made the answer it gives non-deterministic in the sense that it now depends on stuff that happened in layout.

I don't think we want to create that kind of connection, since the intent of the preferred widths computation is that it can run independently of layout, and I don't think you want it to depend on what happens to be going on with layout. This constrains the timing of when the method can be called.

[Dave Hyatt]

Note that this now fails in Firefox, which has moved to a preferred width computation model similar to our own.

[Robert Hogan]

Is this a WONTFIX?

[Ahmad Saleem]

I am not able to reproduce this bug using attached reduction in Safari 15.6.1 on macOS 12.5.1 and it shows "Google" icon on Botton left corner and matches with all other browsers (Chrome Canary 107 and Firefox Nightly 106).

Since all browsers are aligned, I am going to mark this as "RESOLVED INVALID" because Firefox changed to web-spec as per comment 07.