16760 - [dogfood] Textbox deleting entire contents when backspace is depressed

Status: VERIFIED FIXED

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

Description

[Joe Pranevich]

Under the 10/18 build of Mozilla under Windows while attempting to use the
bugzilla form, I will occasionally get a problem where pressing "backspace" will
erase the entire form. It can be reproduced by writing multiple lines of text in
the text box, and then pressing enter several times to add new lines. Click
elsewhere to remove the focus on the form and then click below the text so that
the caret is on one of the (blank) line below. Pressing backspace will cause
entire contents to be deleted. (Or so it appears. I have repoduced this bug
while entering this form. It is possible that the data remains and will be
submitted with the form. If this message appears repeated or garbled, this is
likely the culprit.) I have some difficulty reproducing this each time
 but several attempts almost always does it for me, I have not been able to
narrow down the cause any farther.

Comment 1

[Sean Richardson]

I think I can characterise some of this further:

Steps to Reproduce:
1. Type a line of text into a TEXTAREA, ending with a [Return]
2. Click at the beginning of the line to move the caret there.
3. Type <R><R>dhsjklfh<R>hsdahl<R> where the <R>s are [Return] keys
   and the rest of it is just home-row hash.
4. Click to position the caret somewhere after the beginning of
   what was the first line (now the last).
5. Press the [Delete] key.

Actual Result:
The newly typed text will disappear. All of it.

Expected Result:
A character on the last line wil disappear.

The same sort of thing can be done using the [Backspace] key.

Note that if the caret is repositioned with the arrow-keys
rather than the mouse pointer, the Expected Result occurs.

In general, the text typed between the last and second-last
mouse-pointer-caret-repositioning is in danger if the
{Delete] or [Backspace] key is pressed before any further
typing occurs. (I think).

Careful, too much of this and the browser will crash.

Seen on:
Every Win32 build I've tried (since M10) on Win95 and WinNT.

Comment 2

[buster]

this would probably be easier to debug if it were reproducable in the editor
app.  Any luck reproducing it there, or is this really specific to textarea's?
jan, sujay, can you try to get a consistent reproducable case in the editor app?
not sure why leger is the qu contact on this one, cc-ing sujay.

is this windows only, or all platforms?

Comment 3

[Sean Richardson]

Here is another, very simple reproducible was to see text disappear in
TEXTAREAs:

1. Type a line or two of text, making sure to type to type a carriage-return
   (a.k.a. ENTER) at the end of the last line.
2. Press the [Backspace] key.
3. Press the [Backspace] key again.

Actual Result:
The second [Backspace] keypress erases the entire last line. If the person
entering text has been letting the text wrap on its own and not manually
entering carriage returns, that "line" can be a lot of text over several
visual lines.

Expected Result:
The second [Backspace] keypress erases only the last character of
the last line.

Tested with:
Windows NT 4.0sp3, mozilla.exe, 1999-10-20-08-M11 build.

Sorry, tried to reproduce in Editor with 1999-10-20-08-M11 on WinNT; no luck
with any of the procedures described here. May be TEXTAREA only.

Comment 4

[rubydoo123]

setting this out past dogfood push, setting to M14

Comment 5

[buster]

marking [dogfood]  this behavior discourages people from using the browser to
fill in forms, like bugzilla.  pdt team, your move.  if you think this is PDT+,
please move to M12 and I'll look at it sooner.

Comment 6

[leger]

putting on PDT+ radar.

Comment 7

[rubydoo123]

moving to M12 -- PDT+ push and linking to PDT+ tracking bug 12658

Comment 8

[rubydoo123]

this may be related to 17530, but this hasn't been investigated yet, buster will
probably need help from jfrancis

Comment 9

[leger]

Updating QA Contact

Comment 10

[leger]

Updating QA Contact

Comment 11

[buster]

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

Comment 12

[Simon Fraser [no longer active]]

Will look at it.

Comment 13

[Simon Fraser [no longer active]]

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

Comment 14

[Simon Fraser [no longer active]]

I am unable to reproduce this bug in my current build. If you can reproduce it,
please reopen.

Comment 15

[Akkana Peck]

Simon and I tried to reproduce this on Linux, and weren't able to.  We think
that Joe must have fixed it recently.

Comment 16

[Simon Fraser [no longer active]]

Cc joe to see if he can say what changed here.

Comment 17

[Eli Goldberg]

QA Assigning to self for immediate verification; sujay is out this week, and
verification of PDT+ bugs is #1 goal.

Comment 18

[Eli Goldberg]

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

Comment 19

[Eli Goldberg]

[per jfrancis, this bug is in fact FIXED. Resolving as such so that I can verify
it.]

Comment 20

[Eli Goldberg]

While TEXTAREA seems wholly busted on all platforms checked, I don't see this
particular bug anymore.

[e-mail] & [e-mail], would you like to give your blessings
marking this as verified?

Comment 21

[Sean Richardson]

This looks fixed. Couldn't get it to misbehave today, and it was very easy to
reproduce, earlier.

Tested with: 1999-11-25-09-M12 nightly binary on Windows NT.

Comment 22

[Eli Goldberg]

Verifying as fixed, then. Thanks!