276602 - lines don't flow around zero-width float

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[Henrik Pauli]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041231

There is an image with left and bottom margins, and I want it to float on the
right side.  This is because of how the source is presented to me at the moment,
therefore I have to rely on CSS hacks.  So far Opera and MSIE have been
obedient, regardless of the amount of negative right margin I place on said
image.  As far as my experience goes, the bug is not present in Mozilla if
there's no image inside (but, for example, just a single  ).

The negative right margin is needed because the container is to have a big
enough right margin so that its border shows, and not behind the image (because
that didn't look right).

What I experience is that if the neg. right mar. is smaller than the container's
right margin, all three browser engines behave the same, and as expected.  This
means, that the text after the container respects the margins of the floated image.

However, the moment I increase the neg. right mar. to the size of the
container's margin, or above (in the example soon to be uploaded, this is
106px), mozilla ceases to respect the margins of the image and renders the text
right over it.  Other browsers do not reproduce this.

It's doubtful that the mere size of the margin would have to make such a big
difference and I have a feeling that only one of these is correct.  For my own
sake, I would go with the one that "looks" right, but here I invite the
developers to share their thoughts.

The URL above is valid xhtml 1.1 and css 2.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Henrik Pauli]

Attachment: Screenshot

Just a screenshot taken in latest nightly, see the source of the URL supplied
in the bug for the CSS.

Comment 2

[Mats Palmgren (inactive)]

The problem seems to occur when the float is completely outside the content
area of its containing block.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 4

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

I'm beginning to suspect that what we're doing is correct.

The negative right margin makes the margin-box of the float empty. So we don't
have to avoid it when we're flowing text. Why is this incorrect?

Comment 5

[Henrik Pauli]

But then, please explain why must that float be avoided (i.e. the whole float
itself be protected from text flowing over it) when its container touches it. 
It's hardly wrong, but what's the rationale?

Also I don't see the difference between the two cases really, and I don't really
see the usefulness of this differentiation.  I could perfectly reach the
overflowed case anytime with absolutely positioned stuff and z-indices. 
Meanwhile the "intended result" of the testcase can't be done otherwise as far
as I'm aware.

Comment 6

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

What's strange about this testcase is that the right margin of the float is
negative by more than the width of the element, so the element's margin-box is
empty.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So the rect has a zero width and a height and we treat it as having zero height,
effectively, right?

Ian, what does the spec should actually happen for zero-width floats as far as
flowing around them?

Comment 8

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

This is a bug.  It's a right float, so line boxes cannot go past its left edge.

Comment 9

[Boris Zbarsky [:bzbarsky]]

So then whichever consumer of nsRect.IsEmpty() is involved needs to not use that
method...

Comment 10

[Hixie (not reading bugmail)]

what dbaron said.

Comment 11

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

Related to bug 81710?

Comment 12

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

(In reply to comment #9)
> So then whichever consumer of nsRect.IsEmpty() is involved needs to not use that
> method...

Or IntersectRect or any of our rect operations, really. This code should
probably not be using rects at all.

Comment 13

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

I think there's a bug somewhere on the idea of a "space manager" being the wrong
idea for handling floats.

Comment 14

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

That may be true, but the space manager could prove useful for flowing text into
irregular shapes.

Comment 15

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

Attachment: fix

This is really simple. The real fix is the changes to nsSpaceManager at the end
of the patch; we don't want to jump out on IsEmpty (but zero height means we
have nothing to do). Nothing else in the space manager makes assumptions about
empty rects.

The other changes in the patch are some cleanup of
nsBlockReflowState::FlowAndPlaceFloat to make it easier to understand. The
current code constructs a 'region' rect whose origin is entirely bogus during
most of the lifetime of the function. The code works because it only cares
about the rectangle's size.

Comment 16

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

No changes in visual tests. checked in.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Add this testcase to the regression tests?  ;)

Comment 18

[Boris Zbarsky [:bzbarsky]]

Actually, I just went ahead and did that...