Last Comment Bug 198485 - float:right objects misplaced when in a position:absolute environment
: float:right objects misplaced when in a position:absolute environment
Status: RESOLVED FIXED
[patch]
:
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla1.4alpha
Assigned To: David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
: Hixie (not reading bugmail)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-20 14:41 PST by Christian Eyrich
Modified: 2003-03-21 07:27 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase to show the bug (2.28 KB, text/html)
2003-03-20 14:43 PST, Christian Eyrich
no flags Details
patch (928 bytes, patch)
2003-03-20 16:53 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Splinter Review

Description Christian Eyrich 2003-03-20 14:41:41 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux y686; de-DE; rv:1.4a) Gecko/2003032011
Build Identifier: Mozilla/5.0 (X11; U; Linux y686; de-DE; rv:1.4a) Gecko/2003032011

Using position:relative for the wrapping div paints the "right" box where it is
in the code: at the top right beside the "Hello,". Using position:absolute pulls
it down to the height of the "left" box.

Mozilla changed behaviour with build 2003031204 – builds before (testet
2003031104) put the "right" box in the upper right corner even with
position:absolute.

Reproducible: Always

Steps to Reproduce:
Comment 1 Christian Eyrich 2003-03-20 14:43:22 PST
Created attachment 117917 [details]
Testcase to show the bug
Comment 2 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-20 15:22:04 PST
It's clear the problem is that there's an extra reflow happening without a
PushState/PopState on the space manager.  The question is why.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-20 16:45:56 PST
The problem is the extra call to ReflowDirtyLines on nsBlockFrame.cpp, line
1396, in nsBlockFrame::ComputeFinalSize.  (Why do we have so many different ways
of shrink-wrapping?)
Comment 4 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-20 16:53:04 PST
Created attachment 117948 [details] [diff] [review]
patch

This was a regression from bug 196919 (as I expected).	The caller where the
problem is is the only caller of ClearRegions.
Comment 5 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-20 16:55:00 PST
Taking.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-03-20 18:01:03 PST
Comment on attachment 117948 [details] [diff] [review]
patch

Easy one!
Comment 7 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-20 19:12:24 PST
Fix checked in to trunk, 2003-03-20 19:11 PST.
Comment 8 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-03-21 06:37:46 PST
Thanks for noticing the bug.  (Should be fixed in today's build.)
Comment 9 Christian Eyrich 2003-03-21 07:27:12 PST
Just checked today's build.
Bugfixing at hyperspeed - that's great!

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