Text overlaps floating image if they is in wrapper with padding

RESOLVED FIXED

Status

()

Core
Layout: Floats
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Marat Tanalin, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
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.
(Reporter)

Updated

11 years ago
Component: General → Layout: Floats
Product: Firefox → Core
Version: unspecified → Trunk

Comment 1

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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.
QA Contact: general → layout.floats

Comment 3

11 years ago
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.

Updated

10 years ago
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All

Comment 4

8 years ago
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
No longer blocks: 552426

Comment 5

8 years ago
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 ?

Comment 7

8 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Depends on: 551425
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.