User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 First, it's very strange bug. Following conditions not always discovering it, but it is discovered in testcase available through the bug URL. The bug is discovered next way: if we have wrapper block with padding (100px in testcase) and this wrapper contains floating image (with float: left or float: right) with _not set_ dimensions, then text after image overlaps image. But it is actual only on _first_ load of page or after reload with CTRL+F5 (not just F5). The bug disappears if to resize browser window or press F5 (not CTRL+F5). Bug is also actual only if padding has _certain_ value. For example, in the testcase is 100px and bug is discovered, but if it's for example 50px the bug becomes undiscovered. Finally, it depends on lines quantity in first block that following after image and furthermore this quantity differs in different cases. In the testcase that quantity is 2 (two). It makes no matter is image floated directly or wrapped into floating div. Wrapping one more div into wrapper with padding is workaround for this bug. Explicit setting width _and_ height for image is also workaround for it. Reproducible: Always Steps to Reproduce: See the testcase. Actual Results: Text after first floating image overlaps this image. Expected Results: Text after first floating image should flow around this image. The fact that the bug becomes disappeared on pressing F5 or window resizing allows us to hope that the bug can be resolved by just comparing ways page is rendered in two cases: (1) on initial page load (or after pressing CTRL+F5) [bug appears] and (2) after pressing F5 or after window resizing [bug disappears]. This bug may be (but not necessarily is) related to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=194119 that is now stated as fixed. Firefox 1.5, 2.0 and 3.0pre8 (Gecko/2007081905) are affected by this bug. Hopefully it really can be fixed before so major release as Firefox 3 is shipped.

Bug 194119 – {inc}Paragraph percentage padding based on line-wrapping (CSS padding-left values not recomputed correctly on window resize for block boxes with one and only one inline box child) was duped to Bug 30802 – [BLOCK]{inc} Percentage CSS padding-left values fail on single-line blocks within tables which is verified fixed for Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo] So if you see it at 3.0pre8 (Gecko/2007081905) it is another bug, or du you think the original bug isn't fixed?

to Hermann Schwab: just a few similar symptom data (padding + lines quantity dependence), just supposition, just in case. Probably mentioned bug is just effect of some more deep reason that isn't fixed.

I still see some issues on trunk builds Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007082018 Minefield/3.0a8pre And it happens in these specific conditions: an image without width specified, wrapped in a floated block-level element (whose width is not specified either). Reloading the page 'fixes' the issue always. I think there is still an open bug about images without specified width. Can't find it right away.

I am seeing the very similar thing. (coming from http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=6734 ) Here is another testcase: http://homepage3.nifty.com/chado/moz_work/fob_text_overlap/a02g.html#top The only thing different from the case of URL given by reporter is: Not the image but *text* following image inside the floating box is overlapped with text of sibling box. Next uri links to screen shot complex, showing expected and lapped case, using MS P Gothic and Meiryo font. 1184 x 5127, 797KB: http://homepage3.nifty.com/chado/moz_work/fob_text_overlap/a02g_cap4.png I'm seeing this on WinXP SP3 and Linux (Ubuntu 9.10-ja on VM Guest) with wide range builds including: rv:1.9.3a4pre) Gecko/20100321 Minefield/3.7a4pre ID:20100321073057 rv:1.9.3a4pre) Gecko/20100319 SeaMonkey/2.1a1pre ID:20100319032938 rv:1.9.2.3pre) Gecko/20100321 Namoroka/3.6.3pre ID:20100321042359

Works for me today. Looks resolved for somewhere from rv:2.0b4pre) Gecko/20100811 Minefield/4.0b4pre ID:20100811063038 to rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre ID:20100812040939 . How for you ?

Fixing range pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31bd5d612e6f&tochange=fd26456949ad

(In reply to comment #6) > Fixing range pushlog: > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31bd5d612e6f&tochange=fd26456949ad From that list, bug 551425 is quite an obvious candidate for having resolved this bug. Marking as fixed then.