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.