465935 - Textbox content rendered outside of textbox after resizing window (FF3 Standards Mode only)

Status: NEW

(Core :: Layout, defect)

Description

[Stefan Hübner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.1 (Debian-3.0.1-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.1 (Debian-3.0.1-1)

Firefox 3 has an issue with rendering a textbox' content when resizing the browser window. If input fields move downwards or upwards due to resizing the window, the field's contents don't move with the fields but are rendered exactly where they were before resizing.

The issue described here happens when text above a form breaks down when shrinking the windows width. It only happens in Firefox 3 Standards Mode, when the html's source is condensed (non-pretty HTML).


Detailed description:
We have a form with some longy text above the input fields. The form's html is rendered by Google Web Toolkit (GWT), thus the HTML source is rather condensed and doesn't feature any line breaks. The same form behaves correctly when sources are prettified. But since we use GWT, we don't have any measure to prettify the source.

If the non-prettified form is loaded by firefox and you resize the window after editing the forms textboxes, the textboxes' content is rendered outside the boxes. In Iceweasel, the contents is still visible, on Windows the contents is not visible anymore.

Reproducible: Always

Steps to Reproduce:
1. Load the provided file "form-nonprettified.html"
2. Type some text in the input fields
3. Shrink the window so the text above the form breaks over and the form moves downwards

Actual Results:  
On Iceweasel the textbox' contents is rendered above the actual field. On Windows the contents is invisible.

Expected Results:  
The textboxes need to render their contents correctly under any circumstances.

I'll provide two files to demonstrate the bug:
- "form-nonprettified.html" features the described bug
- "form-prettified.html" is exactly the same code (only prettified) and doesn't feature the described behaviour.

This has been reproduced on
- Debian lenny with running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.1 (Debian-3.0.1-1)
- Windows XP Professional running Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Comment 1

[Stefan Hübner]

Attachment: non-prettified HTML source featuring the bug

Comment 2

[Stefan Hübner]

Attachment: prettified HTML source not featuring the bug (as opposed to "form-nonprettified.html")

Comment 3

[philippe (part-time)]

This works fine on trunk (Gecko 1.9.1 b), however I can reproduce the issue on Gecko1.9.0.x branch (Fx 3.0.x).

On trunk this got fixed between 2008-09-05 2008-09-06
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-05+02%3A04%3A25&enddate=2008-09-06+02%3A10%3A06

Maybe 376662 or 422283.

Comment 4

[Stefan Hübner]

(In reply to comment #3)
> This works fine on trunk (Gecko 1.9.1 b), however I can reproduce the issue on
> Gecko1.9.0.x branch (Fx 3.0.x).
> 
> On trunk this got fixed between 2008-09-05 2008-09-06
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-05+02%3A04%3A25&enddate=2008-09-06+02%3A10%3A06
> 
> Maybe 376662 or 422283.

If I understand you right, upcomping Fx 3.1 will ship with the fix? Is this fix going to make it into Fx 3.0.x too?

Comment 5

[philippe (part-time)]

(In reply to comment #4)
> (In reply to comment #3) 
> > Maybe 376662 or 422283.
> 
> If I understand you right, upcomping Fx 3.1 will ship with the fix? Is this fix
> going to make it into Fx 3.0.x too?

Yes, upcoming Fx 3.1 (and the next beta build) have this fixed - at least on Mac. Check it out:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I doubt it would make it into a maintainance release.