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

NEW
Unassigned

Status

()

10 years ago
9 years ago

People

(Reporter: sthuebner, Unassigned)

Tracking

1.9.0 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

10 years ago
Created attachment 349170 [details]
non-prettified HTML source featuring the bug
(Reporter)

Comment 2

10 years ago
Created attachment 349171 [details]
prettified HTML source not featuring the bug (as opposed to "form-nonprettified.html")

Comment 3

10 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Version: unspecified → 1.9.0 Branch
(Reporter)

Comment 4

10 years ago
(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

10 years ago
(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.
You need to log in before you can comment on or make changes to this bug.