Closed
Bug 299367
Opened 19 years ago
Closed 18 years ago
{inc}Float not repositioned after image is loaded
Categories
(Core :: Layout: Floats, defect)
Core
Layout: Floats
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: anlan, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
858 bytes,
text/html
|
Details | |
1.64 KB,
patch
|
dbaron
:
review+
dbaron
:
review-
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
Do a forced reload to refetch image. Lower blue bar (<div>) is positioned over the text, not pushed below.
Reporter | ||
Comment 2•19 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•19 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
Assignee | ||
Comment 4•19 years ago
|
||
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•19 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+
Assignee | ||
Comment 6•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.9a1?
Reporter | ||
Comment 7•19 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?
Assignee | ||
Comment 8•19 years ago
|
||
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•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 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.
Description
•