Closed Bug 27951 Opened 20 years ago Closed 20 years ago

<INPUT TYPE="RESET"> doesn't clear text field


(Core :: Layout: Form Controls, defect, P3)






(Reporter: djoham, Assigned: pollmann)



(Whiteboard: fix in hand)


(3 files)

From Bug Helper:
User-Agent: Mozilla/4.61 [en] (X11; I; Linux 2.2.12-20 i686)
BuildID:    2000021510
Sometime between the release of M13 and this build, the intput type of RESET
doesn't seems to have been broken.

The test case I'm submitting works as expected on Linux Netscape 4.x as well as
in Linux Mozilla M13. Something must have regressed....
Reproducible: Always
Steps to Reproduce:
1.fill in some text on a form with a reset button on the reset button 
Actual Results:  nothing happens		
Expected Results:  the text box should be cleared.
Attached file test case
This sounds like a dup of bug 3547. If this is the case, then bug 3547 has
Component: Browser-General → Form Submission
Confirmed on Linux build 2000.02.21.08. Reassign to component owner.
Summary: <INPUT TYPE="RESET"> Doesn't work → <INPUT TYPE="RESET"> doesn't clear text field
Oops. Forgot to check the right box.  Reassigning for real now.
Assignee: leger → karnaze
QA Contact: cbegle → ckritzer
Reassigning to Eric.
Assignee: karnaze → pollmann
narrowing down the time when this regression was introduced:
this bug does not occur with 2000020509 linux rh6.1
this bug occurs with 2000020708 linux rh6.1
This bug only occurs if the text input has value="" or value attr not given:
<input type=text value=""> or <input type=text>

This bug does not occur if the text input has non-empty value attr, for example:
<input type=text value="1234">
Here is what gdb is showing me:

It looks this bug 27951 was introduced when
editor/base/nsTextEditRules.cpp rev 1.97 landed.
nsTextEditRules needs to be modified to correct this.

in layout/html/forms/src/nsGfxTextControlFrame.cpp:
The nsGfxTextControlFrame calls this function:
when aValue == "" nothing happens, and when aValue != "" it works fine.

in editor/base/nsHTMLEditor.cpp:
inside nsHTMLEditor::InsertText(), this function is called:
result = mRules->WillDoAction(selection, &ruleInfo, &cancel, &handled);

then calls:

Take a look at this code, it shows why this problem is happening:
Adding jfrancis to cc-list,
he committed editor/base/nsTextEditRules.cpp rev 1.97
Thanks Matt for excellent work debugging this one!

 I'm going to hand it off to to find an alternate hack for
IME or setting a text field to "".  Also CC'ing buster, the GfxTextControlFrame
Assignee: pollmann → jfrancis
Component: Form Submission → HTML Form Controls
OS: Linux → All
Hardware: PC → All
You should not need to ever call InsertText() with an empty string.  What are you 
trying to do?  If you are trying to clear the string this is not the way to do 
handing back to pollmann to make sure i find out what's up...
Assignee: jfrancis → pollmann
Yes, it appears that the code in nsGfxTextControlFrame is trying to set the text
of the input using the InsertText call.  What is the correct call to make here?

Buster might have more information on this.  The code in question is 
 nsGfxTextControlFrame::SetTextControlFrameState() around line 1372.  It appears
to be trying to set the complete contents of the editor.

Handing it back to jfrancis for an answer.  (Feel free to bounce it back to me) 
This bug is a hot potato!  :)
Assignee: pollmann → jfrancis
ok - i'm looking into this...
In nsGfxTextControlFrame::SetTextControlFrameState(), try making these changes:

      // get the flags, remove readonly and disabled, set the value, restore 
      PRUint32 flags, savedFlags;
      flags = savedFlags;
      flags &= ~(nsIHTMLEditor::eEditorDisabledMask);
      flags &= ~(nsIHTMLEditor::eEditorReadonlyMask);
+     mEditor->SelectAll();
+     mEditor->DeleteSelection(nsIEditor::eNone);

Note that the lines with the "+" are new (and don't include the +, obviously).
SelectAll(), then DeleteSelection() is the right way to clear out the string.

back to pollmann....
Assignee: jfrancis → pollmann
*** Bug 30458 has been marked as a duplicate of this bug. ***
I think they may also happen if the input type is file... Enclosing attachment.
I think they may also happen if the input type is file... Enclosing attachment.

Yes, this is happening with text inputs, text areas, and password, and file
inputs.  The fix that jfrancis proposed takes care of this bug.  I'll check it
in when the tree opens for general checkins.  Thanks!
Whiteboard: fix in hand
Target Milestone: M15
*** Bug 31329 has been marked as a duplicate of this bug. ***
Closed: 20 years ago
Resolution: --- → FIXED
I just checked in jfracis's fix.

To verify this fix, go to the above testcases.  Clicking on Reset should clear

the inputs for all of them.  Thanks!

*** Bug 27835 has been marked as a duplicate of this bug. ***
Updating QA contact.
QA Contact: ckritzer → bsharma
verified fixed - buildID : 2001-08-06-09trunk
You need to log in before you can comment on or make changes to this bug.