Bug 33245 – Second right floated image misplacment

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Benjamin Jay Young]

In firefox, ie, opera the page (http://www.blahertech.org/about/staff) displays fine. However when using a webkit browser such as chrome and safari, my left floated images are displaying in misplaced areas. There is no known CSS issue that I know of that would be causing this, since I have cleared both sides.

[Benjamin Jay Young]

Excuse me, I meant right floated.

This behaves the way I would expect it to behave, given the <br> elements with "clear: both;" but perhaps I am missing something. A reduction would help.

[Benjamin Jay Young]

The br element is before the floated image. It should behave just as the image above it and have the text wrap around it. Yet the text seems to be behaving as if the br element is below the image, which it's not.

The only reason I would expect this behavior is if the h3 tag would be clearing it, however this is not the case since the above method is repeated above and everything responds normally.

[Benjamin Jay Young]

Excuse me again, I meant the br element is above the image.

<rdar://problem/7546035>

Created attachment 46784 [details]
Test case

This is based on the original page. It demonstrates how incremental layout can lead to wrong behavior.

Created attachment 46787 [details]
Test case

Simplified test case

See bug 19278. When the last line contains a line break, the floats vector for that line may potentially contain both floats occurring before the line break and floats occurring after the line break. For example,
<img align="right"><br><img align="right">

Later, during incremental layout, when the line with the line break happens to be the last clean line, both kinds of floats are “restored”. If the <br> happens to be clearing, it will try to clear both, although it should not clear the image that comes after it.

Perhaps the solution is not to put the “after the line break” floats in the next line box’s floats vector. When there is no next line box, make one.

(In reply to comment #8)
> Perhaps the solution is not to put

I meant “…the solution is to put…”.

Created attachment 46797 [details]
Work in progress

First cut. Breaks repaint and hit-testing due to the extra line. May want to have a RootInlineBox subclass for that, with virtualHeight().

Created attachment 46837 [details]
Create a root line box for trailing floats after the line break on the last line

[Darin Adler]

Comment on attachment 46837 [details]
Create a root line box for trailing floats after the line break on the last line

Neither the change log nor the source files explain the role of this additional box. I think you need a one-sentence comment stating what, to you, is obvious.

> +    TrailingFloatsRootInlineBox(RenderObject* obj) : RootInlineBox(obj)

I would call this "object", not "obj".

> +    virtual int virtualHeight() const { return 0; }

I would make this member function private. It would be a programming error to call this with a TrailingFloatsRootInlineBox*.

http://trac.webkit.org/projects/webkit/changeset/53420
http://trac.webkit.org/projects/webkit/changeset/53421

[Eric Seidel (no email)]

Looks like this is a failure on the Gtk bots:
http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r53420%20(2468)/fast/dynamic/float-in-trailing-whitespace-after-last-line-break-2-pretty-diff.html

Do they just need a new baseline?