594303 - :first-letter pseudo element with float value has an impossible-to-change clear value

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[Jean-Philippe HALIMI]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5) Gecko/20100101 Firefox/4.0b5
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5) Gecko/20100101 Firefox/4.0b5

I tried to make the easiest code to show you here :
http://jpallone.free.fr/bugzilla.html

When you have an element floating right and a :first-letter pseudo-class floating left, this :first-letter pseudo-class is cleared by left, only with Firefox 4b4+. I tried SRware Iron (Chrome/ium), Opera and IE and it seems that Firefox 4b4+ is the only one to do the same.

Actually, I found this bug with my website which has the same problem (including when reading articles) :
http://www.pokemonespace.com/

Reproducible: Always

Steps to Reproduce:
1. Just try the code here : http://jpallone.free.fr/bugzilla.html


Expected Results:  
Try any other browser to see the correct result.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: Reporter's Testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bbefb7bcb41e&tochange=26ee1b556bd9

Looks like fallout from bug 563584.

Comment 4

[Bamm Gabriana]

If the page has a :first-letter pseudo-element with a "float: left" value, and

1) if the page does not have an element with a "float: right" value, the :first-letter pseudo-element is rendered correctly.

2) if the page has an element with a "float: right" value, the :first-letter pseudo-element is rendered correctly for a fraction of a second, and then suddenly falls down right just below the bottom level of the element with the  "float: right".

This is the way it works in my website:
http://www.pyxis.astronomy.com.ph/

Some pages have a "float: right" and some don't. The bug only affects pages that do. I can see in my page that it gets rendered correctly for a split second before it falls down to a level below the right-floated element.

Comment 5

[Bamm Gabriana]

The title says it has an impossible-to-change clear value; however my CSS does not use a clear value. I don't think this problem has something to do with the first letter getting cleared.

Comment 6

[Jean-Philippe HALIMI]

@Bamm Gabriana> Whatever my problem was, it seems your bug and mine is a fallout from some issues that appeared in the float manager. I wrote that there was a specific clear value but I did not use it in my example code. 

Your problem is the same as me. You've got a "float: right" picture, and then a "float: left" :first-letter pseudo-element, so it falls down behind the picture, as if it was cleared.

Comment 7

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

I think I know what's going on:  I assumed that floats all have their width computed in the reflow state, but a :first-letter isn't a block and therefore doesn't, so nsBlockReflowState::FlowAndPlaceFloat pushes it down.

Possible fixes:

 (1) use our intrinsic width APIs to set an appropriate width in the reflow state for floating first letters

 (2) force floating :first-letters to never be pushed down  (but, really, if they don't fit we really want to push down both the first letter and the rest of the word)

Comment 8

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

(3) make floating first-letter use a more inline-like reflow, but still take up space in the float manager

Comment 9

[Bamm Gabriana]

@David: So which of the three possible fixes you mentioned is the most probable path?

Comment 10

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

I don't know yet; that's why I listed three options rather than one.

Comment 11

[Bamm Gabriana]

Shouldn't this block Firefox 4? Many sites are affected.

Comment 12

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

It already does; see blocking2.0:betaN+.

Comment 13

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

(In reply to comment #7)
>  (1) use our intrinsic width APIs to set an appropriate width in the reflow
> state for floating first letters

This is hard because our intrinsic width APIs don't actually work on first letter because first letter computations happens during reflow rather than frame construction.

Comment 14

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

Attachment: patch

Well, this is ugly, but it's the easy way to get the old behavior back.

Comment 15

[Bamm Gabriana]

> I assumed that floats all have their width computed
> in the reflow state, but a :first-letter isn't a block
> and therefore doesn't

Is a :first-letter the only thing that doesn't have its width computed in the reflow state? Would it be possible to have all non-block elements computed instead of isolating the :first-letter case?

Comment 16

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

:first-letter is the only case of a non-block being a float, since the 'float' property being other than 'none' forces an element to be a block; see CSS 2.1 section 9.7: http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo

Comment 17

[Boris Zbarsky [:bzbarsky]]

> first letter computations happens during reflow

Can we do it during intrinsic width computation too?  Or not so much?

Comment 18

[Bamm Gabriana]

Thanks for the explanation. I was just worried that something else might come up which wasn't covered by the current solution.

I thought if would be "prettier" to we can find all floating non-blocks and set a width, but as you mentioned this only affects first letters so it should not matter.

Comment 19

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

(In reply to comment #17)
> > first letter computations happens during reflow
> 
> Can we do it during intrinsic width computation too?  Or not so much?

I think right now it's pretty tied in to reflow logic, and it really belongs in frame construction anyway.

Comment 22

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

Fixed on mozilla-central: http://hg.mozilla.org/mozilla-central/rev/44d18ee0102f

Please note that the fix is NOT in beta 7.