Matthias Kerkhoff Reporter
	Description • 25 years ago

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (WinNT; U)
BuildID:    2000071020

Setting the line-height property leads to some very strange effects in a 
TEXTAREA. This bug-report shows, that setting the line-height on a TEXTAREA 
_and_ causing a horizontal scrollbar to appear, may cause invisible text (don't 
know how to describe the effect better)

Reproducible: Always
Steps to Reproduce:
1. Load the attached testcase
2. Enter text in the first line of the textarea until a horizontal scrollbar 
appears.
3. Enter [RETURN]
4. (Try to) enter more text

Actual Results:  The text in the secont line is invisible until the third line 
is begun (and so on).

Expected Results:  Any entered text should be visible.

	rods (gone)
	Comment 2 • 25 years ago

The attachment looks fine, I don't see a problem

	Matthias Kerkhoff Reporter
	Comment 4 • 25 years ago

Using build 2000071108 I found that selecting, deselecting and deleting partial 
contents of the textarea may also cause Mozilla to crash. I _assume_ that this 
is related to the line-height problems and add the crash keyword. 
Please mail me if you need further config-infos or are still unable to reproduce 
the bug.

	rods (gone)
	Comment 5 • 25 years ago

This may be a buster bug, but I will start out with editor because he is gone

	rubydoo123
	Comment 6 • 25 years ago

this is working fine on win98, the line height is being honored and the text is 
getting inserted correctly. Sujay, can you test this on Mac & Linux?

	sujay
	Comment 7 • 25 years ago

works fine on linux.

	timeless
	Comment 8 • 25 years ago

2000071308win32 windows2000
type the text in either (easier w/ the horizontal), eventually you will get 
invisible characters.
example, type one long string (no spaces) until you get a scrollbar, press 
space and type stuff. Stuff is invisible; selection and certain other features 
cause text to paint.

w/ vertical, if there's text to the right of the cursor we have serious 
painting issues. w/ serif font, pixels above the top line for j (exclude dot) 
remains from characters that have shifted, new character's bottoms are painted 
(each scroll fixes this)

	kinmoz
	Comment 9 • 25 years ago

I can reproduce the problem with my 07/17/00 Win32 debug build.

	kinmoz
	Comment 10 • 25 years ago

I'll take a look at this one and see if I can figure out what is going on and
fix it by the nsbeta2 cutoff date this Friday (07/21/00).

	Jay Patel [:jay]
	Comment 11 • 25 years ago

Putting on [nsbeta2-] radar. Not critical to beta2. 

	rubydoo123
	Comment 12 • 25 years ago

setting to correctness and nsbeta3

	kinmoz
	Comment 13 • 25 years ago

Accepting bug.

	rubydoo123
	Comment 14 • 25 years ago

setting to nsbeta3+

	rubydoo123
	Comment 15 • 25 years ago

*** Bug 45934 has been marked as a duplicate of this bug. ***

	Chris McAfee
	Comment 16 • 25 years ago

I occasionally see this on the tinderbox admin page,
I have to highlight what I just typed to see it.
Very annoying.

	rubydoo123
	Comment 17 • 25 years ago

setting priority in status whiteboard

	kinmoz
	Comment 18 • 25 years ago

*** Bug 46932 has been marked as a duplicate of this bug. ***

	Jeffrey Baker
	Comment 19 • 24 years ago

Tested and broken on Linux 2000080421 (M18).  Changing platform and opsys to
all/all.  I made a testcase for bug 47780, and I noticed that it isn't just the
line-height CS property that causes this.  Anything that changes the line height
also has this problem.  e.g. font-size causes the problem perfectly well.

	Jeffrey Baker
	Comment 20 • 24 years ago

*** Bug 47780 has been marked as a duplicate of this bug. ***

	Chris McAfee
	Comment 21 • 24 years ago

new summary?

	Jeffrey Baker
	Comment 22 • 24 years ago

*** Bug 48221 has been marked as a duplicate of this bug. ***

	kinmoz
	Comment 23 • 24 years ago

*** Bug 48540 has been marked as a duplicate of this bug. ***

	kinmoz
	Comment 24 • 24 years ago

Changing summary from "Setting line-height in TEXTAREA may lead to invisible
text" to "Typed text does not render in TextAreas with a horizontal scrollbar".


nsBlockFrame::ReflowDirtyLines() is suppressing Block/Line level invalidations 
that happen when IsIncrementalDamageConstrained() returns true. This was an 
optimization, added by buster@netscape.com, for Ender-Lite GFX Text widgets so 
that invalidations didn't ripple up it's parent frame hierarchy and cause things 
outside the text widget to paint every time content is added to the text widget.

The only reason why text currently shows up when typing in a GFX single line 
textfield or textarea, with no horizontal scrollbar, is because the internal 
scroll frame for the TextField/TextArea constantly resizes itself (invalidating 
the entire scroll frame) causing the entire contents of the widget to be redrawn 
... it stops resizing when a horizontal scrollbar appears ... once this happens, 
the only time anything will redraw in a text widget, is if it is invalidated at 
the nsTextFrame level.

nsTextFrame::Reflow() only invalidates when it is handling an incremental 
reflow, and currently, it is invalidating the wrong rect on the screen. I have a 
fix for this and will attatch it to this bug. This fixes most of the problems we 
see, except for the case where we are typing the first character on a blank 
line. It doesnt work for the first character case because the text frame is 
created and reflowed with it's reason set to 'Resize' ... which means that no 
invalidation happens in nsTextFrame::Reflow(), probably because it's dimensions 
are set by the nsLineLayout code, after nsTextFrame::Reflow() exits.

I will check in my code that fixes the invalidations in nsTextFrame, but I'm 
passing this bug on to buster@netscape.com to figure out how to fix the first 
character on the line problem.

	kinmoz
	Comment 26 • 24 years ago

I checked in the nsTextFrame::Reflow() patch:

    mozilla/layout/html/base/src/nsTextFrame.cpp   revision 1.272

	buster Assignee
	Comment 27 • 24 years ago

I have a fix in hand for the remaining problems.  
Marc showed me another symptom of this same problem, which has to do with just 
typing in a textarea.  That is also fixed.

	Chris Waterson
	Comment 29 • 24 years ago

Ouch: this seems sort of klunky. Why is it that a text frame does not know how
to invalidate itself on its initial reflow? 

	kinmoz
	Comment 30 • 24 years ago

It's probably because the text frame does not know it's height during it's
initial reflow ... the line layout code sets the text frame's height after it
has reflowed and calculated the heights of all the other frames on the line.

	buster Assignee
	Comment 31 • 24 years ago

fix checked in.
r=kin

	sujay
	Comment 32 • 24 years ago

verified in 8/28 build.