Closed Bug 15743 Opened 25 years ago Closed 25 years ago

[dogfood] can't edit in bugzilla form field

Categories

(Core :: DOM: Editor, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: kinmoz)

Details

(Whiteboard: Fix exists, needs review by kipp@netscape.com or troy@netscape.com)

I've been trying to use mozilla to file bug reports, and I've found that after typing a few lines into the description area, the text edit widget becomes unusable: - the cursor will be drawn in the wrong place - trying to use the right arrow to go to the end of the line wraps around to arbitrary places in the text - ends of lines will disappear - typing past the end of the visible area doen't scroll to keep the cursor visible - etc.
Assignee: buster → kin
Severity: normal → blocker
Priority: P3 → P1
Target Milestone: M11
assigned to kin. looks like a display problem. this is a high priority blocker.
Status: NEW → ASSIGNED
Accepting bug.
This looks like a reflow problem. To reproduce, load the following HTML into apprunner or viewer: <html> <body> <form> <textarea cols=10 rows=5></textarea> </form> </body> </html> Keep typing some text in the textare until the text wraps to the 2nd line. If you keep typing, you'll notice that the text gets clipped once it hits the right edge of the textarea, and it never wraps. You'll also notice that the cursor is sitting at the beginning of the line. If you turn on visual debugging in viewer, you can see that it looks like the text frame for the 2nd line is only big enough to contain the first few characters of the 2nd line, everything else is being drawn outside the frame. Cc'ing troy@netscape.com.
Whiteboard: Fix exists, needs review by kipp@netscape.com or troy@netscape.com
Okay I have a fix that kipp@netscape.com and troy@netscape.com have to look at. What was happening was nsTextFrame::Reflow() was setting measureText to false when reflowing during a resize while we were in a block that was preformatted and wrapping. I added a check for that case to the if statement that was checking for conditions where we could skip measuring text. Index: nsTextFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v retrieving revision 1.177 diff -c -r1.177 nsTextFrame.cpp *** nsTextFrame.cpp 1999/09/29 20:36:00 1.177 --- nsTextFrame.cpp 1999/10/08 17:15:15 *************** *** 2534,2540 **** if (!mNextInFlow && (mState & TEXT_OPTIMIZE_RESIZE) && (maxWidth >= realWidth) && !aMetrics.maxElementSize && (lastTimeWeSkippedLeadingWS == skipWhitespace) && ! (!ts.mPreformatted || (prevColumn == column))) { // We can skip measuring of text and use the value from our // previous reflow measureText = PR_FALSE; --- 2534,2541 ---- if (!mNextInFlow && (mState & TEXT_OPTIMIZE_RESIZE) && (maxWidth >= realWidth) && !aMetrics.maxElementSize && (lastTimeWeSkippedLeadingWS == skipWhitespace) && ! (!ts.mPreformatted || ! (prevColumn == column && ts.mPreformatted && !wrapping))) { // We can skip measuring of text and use the value from our // previous reflow measureText = PR_FALSE;
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked in by troy@netscape.com. Here are his comments from the CVS log: nsTextFrame.cpp revision 1.178 Fix for blocker #15839. r=kipp@netscape.com,kin@netscape.com Typing into a text area wasn't working properly. Problem was that when the text changed we were reflowing the text frames with a resize reflow command and we thought we could optimize the reflow. So I changed ContentChanged() to mark each text frame dirty so we would know not to do the optimization
Status: RESOLVED → VERIFIED
I just tried it....much more usable...verified in 10/13 build.
You need to log in before you can comment on or make changes to this bug.