Closed
Bug 45152
Opened 25 years ago
Closed 24 years ago
Typed text does not render in TextAreas with a horizontal scrollbar
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: make, Assigned: buster)
References
Details
(Keywords: testcase, Whiteboard: [nsbeta3+][p:1])
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•25 years ago
|
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 3•25 years ago
|
||
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.
Keywords: crash
Comment 5•25 years ago
|
||
This may be a buster bug, but I will start out with editor because he is gone
Assignee: rods → beppe
Status: ASSIGNED → NEW
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?
Updated•25 years ago
|
QA Contact: ckritzer → sujay
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)
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).
Comment 11•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [07/21] → [nsbeta2-] [07/21]
Comment 12•25 years ago
|
||
setting to correctness and nsbeta3
Whiteboard: [nsbeta2-] [07/21]
Target Milestone: M17 → M18
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.
Comment 17•25 years ago
|
||
setting priority in status whiteboard
Whiteboard: nsbeta3+ → [nsbeta3+][p:3]
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.
OS: Windows NT → All
Hardware: PC → All
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.
Assignee: kin → buster
Severity: major → critical
Status: ASSIGNED → NEW
Priority: P3 → P1
Summary: Setting line-height in TEXTAREA may lead to invisible text → Typed text does not render in TextAreas with a horizontal scrollbar
Whiteboard: [nsbeta3+][p:3] → [nsbeta3+][p:1]
Comment 25•24 years ago
|
||
Comment 26•24 years ago
|
||
I checked in the nsTextFrame::Reflow() patch: mozilla/layout/html/base/src/nsTextFrame.cpp revision 1.272
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.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1] [fix in hand]
Assignee | ||
Comment 28•24 years ago
|
||
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?
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.
Assignee | ||
Comment 31•24 years ago
|
||
fix checked in. r=kin
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][p:1] [fix in hand] → [nsbeta3+][p:1]
You need to log in
before you can comment on or make changes to this bug.
Description
•