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.
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bbefb7bcb41e&tochange=26ee1b556bd9 Looks like fallout from bug 563584.
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.
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.
@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.
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)
(3) make floating first-letter use a more inline-like reflow, but still take up space in the float manager
@David: So which of the three possible fixes you mentioned is the most probable path?
I don't know yet; that's why I listed three options rather than one.
Shouldn't this block Firefox 4? Many sites are affected.
It already does; see blocking2.0:betaN+.
(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.
Created attachment 478109 [details] [diff] [review] patch Well, this is ugly, but it's the easy way to get the old behavior back.
> 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?
: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
> first letter computations happens during reflow Can we do it during intrinsic width computation too? Or not so much?
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.
(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.
Fixed on mozilla-central: http://hg.mozilla.org/mozilla-central/rev/44d18ee0102f Please note that the fix is NOT in beta 7.