180711 - position:relative blocks don't flow around floats

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect, P1)

Description

[Heribert Schuetz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

A DIV with style="position: relative;" following a table with align="left" is
displayed on top of the table instead of to its right.


Reproducible: Always

Steps to Reproduce:
1. Open the URL http://www.maffei.de/index.cfm?fuseaction=spektrum.main&navi=1,0,0
Actual Results:  
The content of some DIV element is written on top the content of some TABLE element.

Expected Results:  
Display the DIV content to the right of the TABLE content.

I don't know what the standards require here, but NS 4.78, IE, and Konqueror do
the same thing, while Mozilla (Moz. 1.0.1, Moz. 1.2b, NS 7.0) behaves differently.

Comment 1

[Heribert Schuetz]

Perhaps this is a duplicate of bug 118940.

Comment 2

[Heribert Schuetz]

Attachment: minimal test case

Comment 3

[Hixie (not reading bugmail)]

Does this still break if the table is replaced with just a block?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simpler testcase

No TABLEs.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Stupid default parameters.  We should get rid of all of those at some point.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

taking

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(BTW, the value used in the CreateContinuingFrame case shouldn't matter, because
nsBlockFrame::Init copies all the block-range flags from the prev-in-flow.  And
using 0 means I don't need a line break.)

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

BTW, thanks (to the reporter) for the simple testcase for this rather serious bug.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed bug 180725 on getting rid of all those default parameters.

Comment 10

[Madhur Bhatia]

see this on win2k.
platform -> all

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 106671 [details] [diff] [review]
patch

Heh.  Gotta love that comment-flatly-contradicts-code thing we had going... ;)

Comment 12

[Bernd]

Ahh, a silent removal of NS_BLOCK_WRAP_SIZE, I like that :-)

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 106671 [details] [diff] [review]
patch

Actually, this patch is wrong.	We need to go through ConstructBlock since we
need these state bits in some cases.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, never NS_BLOCK_WRAP_SIZE, but sometimes NS_BLOCK_SPACE_MGR|NS_BLOCK_MARGIN_ROOT.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This is the corrected patch (see my previous comment).

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oops, I forgot the nsCSSFrameConstructor.h change in the patch.  But it's the
obvious -1/+2 change, so I won't bother with a new patch.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 185175 has been marked as a duplicate of this bug. ***

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 109197 [details] [diff] [review]
patch

r+sr=roc+moz

But, are you sure there are no cases left where area frames need to wrap their
overflowing children?

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The places changed in the patch were the only ones that used the default
parameter, which I removed.  There are other things that use NS_BLOCK_WRAP_SIZE,
but that's a separate issue...  I'm not quite sure what you were asking, though.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I was worried about the call to NewAreaFrame from CreateContinuingFrame, but I
guess if the area frame has a continuation then it can't be wrapping its
content. Can it? Hmm.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See comment 7 about the call in CreateContinuingFrame.

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2002-12-13 12:13 PDT.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Ah, excellent.

Comment 24

[R.K.Aa.]

It seems this fix made http://forum.fok.nl/showtopic.php/254505 look like a mess.
(bug 191291). All other browsers i've tested display the page well.
Opera, for instance, display both the url above as well as the original url in
this bug (180711) well.

Also all Mozilla and Netscape builds up till this fix also show the url in bug
191291 well.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There's no reason we should imitate a bug in WinIE for *only* 'position:
relative' blocks.  (Because we had this bug for so long, web sites probably
thought that it wasn't a bug.)

Comment 26

[R.K.Aa.]

Well.. it's wrong to call it a "WinIE bug". Netscape 4.*, 6.*, 7.*, Mozilla 1.*
up untill this fix, in addition to Opera 6.11 and Konqueror 3.0.1 show it
approximately like MSIE. Mozilla builds from the past months is the only browser
that fails, actually.

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 82852 has been marked as a duplicate of this bug. ***