Last Comment Bug 299367 - {inc}Float not repositioned after image is loaded
: {inc}Float not repositioned after image is loaded
Status: RESOLVED WORKSFORME
: regression, testcase
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
: Jet Villegas (:jet)
Mentors:
http://www.ida.liu.se/divisions/sas.e...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-01 06:09 PDT by Andreas Lange
Modified: 2006-08-17 16:03 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (858 bytes, text/html)
2005-07-01 06:15 PDT, Andreas Lange
no flags Details
fix (1.64 KB, patch)
2005-07-06 21:45 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review+
dbaron: review-
dbaron: superreview+
Details | Diff | Splinter Review

Description Andreas Lange 2005-07-01 06:09:28 PDT
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.
Comment 1 Andreas Lange 2005-07-01 06:15:28 PDT
Created attachment 187932 [details]
Testcase

Do a forced reload to refetch image.

Lower blue bar (<div>) is positioned over the text, not pushed below.
Comment 2 Andreas Lange 2005-07-01 07:22:52 PDT
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 Andrew Schultz 2005-07-01 21:53:55 PDT
this regressed between linux trunk 2005042805 and 2005042901.  There are a lot
of layout changes in that frame, but nothing that looks directly relevant.
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-07-06 21:45:10 PDT
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.
Comment 5 Andreas Lange 2005-07-14 01:12:54 PDT
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.
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-07-25 15:50:57 PDT
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.
Comment 7 Andreas Lange 2006-01-13 06:52:16 PST
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?
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-01-15 13:33:30 PST
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).

Note You need to log in before you can comment on or make changes to this bug.