{inc}Float not repositioned after image is loaded

RESOLVED WORKSFORME

Status

()

Core
Layout: Floats
RESOLVED WORKSFORME
12 years ago
11 years ago

People

(Reporter: Andreas Lange, Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
This problem is present on current mozilla trunk, tested on my own Solaris build
and a Mac nightly. It is a regression from 1.7.

The problem is visible on the page given in the URL on the first load. Reloading
relayouts correctly. Doing a clean reload redisplays the problem as the image is
then refetched.

What seems to be happening is that all text elements on the page are laid out
and rendered. Then the image comes in, and the content text (all the "a":s) is
pushed down. In previous versions, this will also push down the bottom blue bar.
In current CVS the blue bar will remain in the same position - over the content
text it previously was position below.

One strange css dependecy is that the "margin-bottom:20px;" in the top blue bar
seems significant.

Will attach a simplified testcase next.
(Reporter)

Comment 1

12 years ago
Created attachment 187932 [details]
Testcase

Do a forced reload to refetch image.

Lower blue bar (<div>) is positioned over the text, not pushed below.
(Reporter)

Comment 2

12 years ago
There are a bunch of similar bugs:

Bug 177365 {inc} Page not reflowed correctly when image arrives and image size
becomes known
Bug 195368 Undimensioned float image does not cause reflow when loaded
Bug 221315 {inc}text over floated div when unsized image not in cache
Bug 257552 CSS Floats do not layout properly when page is first viewed or after
the cache is cleared
Bug 289406 floated elements vertically misaligned on initial render

I think a difference is that all of those fail with older versions (<=1.7),
while the testcase in this bug is broken only in > 1.7. Might be the same basic
problem though.

Someone taking a stab at this could probably fix several of the bugs at once.
Some of them have useful testcases, not all are confirmed.

Comment 3

12 years ago
this regressed between linux trunk 2005042805 and 2005042901.  There are a lot
of layout changes in that frame, but nothing that looks directly relevant.
Keywords: regression, testcase
Summary: Float not repositioned after image is loaded → {inc}Float not repositioned after image is loaded
Created attachment 188512 [details] [diff] [review]
fix

We should check the line's overflow area when we check to see if it's impacted
by float damage, because floats and overflowing lines might leak out of its
bounds and be impacted.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #188512 - Flags: superreview?(dbaron)
Attachment #188512 - Flags: review?(dbaron)
(Reporter)

Comment 5

12 years ago
Comment on attachment 188512 [details] [diff] [review]
fix

Tested the patch - it fixes the testcase and other URLs I can come up with.
Thanks!

I also checked the similar bugs listed in comment 2. None of them are related
to this regression. Bug 195368 and bug 257552 have good testcases and still
fail, but  bug 177365, bug 221315 and bug 289406 are (probably) WFM now.
Attachment #188512 - Flags: superreview?(dbaron)
Attachment #188512 - Flags: superreview+
Attachment #188512 - Flags: review?(dbaron)
Attachment #188512 - Flags: review+
Actually I just noticed that the combined area includes relative positioning but
mBounds doesn't. I think we want to check for damage *before* accounting for
relative positioning. I'll have to revise the patch to do that, and it won't be
trivial.
Flags: blocking1.9a1?
(Reporter)

Comment 7

12 years ago
I am unable to reproduce the testcase on fx1.5 or current seamonkey trunk. The code in nsBlockFrame that attachment 188512 [details] [diff] [review] regards is unchanged in CVS so a fix went in somewhere else. However:

(In reply to comment #6)
> Actually I just noticed that the combined area includes relative positioning
> but
> mBounds doesn't. I think we want to check for damage *before* accounting for
> relative positioning. I'll have to revise the patch to do that, and it won't be
> trivial.
> 

I guess the above problem still stands though? Should this bug be morphed or resolved WFM and another one opened?
Let's make this WFM. If someone can create a testcase that shows the problem I suspect, then they can file a new bug.

I'm not 100% sure that the exact bug I was trying to fix here exists. It could only exist if you have a block B with an overlowing child element C, and a float F not a descendant of B where F does not intersect B's normal dimensions vertically, and changing F's size or position should change the placement of C (but doesn't).

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9a1?
Resolution: --- → WORKSFORME
Attachment #188512 - Flags: review-
You need to log in before you can comment on or make changes to this bug.