Open Bug 524360 Opened 15 years ago Updated 2 years ago

Pressing of escape key will auto - reinput the value which has been modified during onkeyup event

Categories

(Core :: DOM: Events, defect, P5)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: wyeechen, Unassigned)

Details

Attachments

(2 files)

This is a html file contains the script, which demonstrat how the 'escape' key reinput the origin value
457 bytes, text/html
Details
A More concrete example
339 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

After changing an textbox input's value under onkeyup event, press 'escape' key will re-input the origin value. 

Reproducible: Always

Steps to Reproduce:
1. Open a webpage that contains script showns in the 'Additional Information'.
2. Type 'abc' on the textbox;
3. The textbox's value shall be cleared automatically by the onkeyup event.
4. Press 'escape' key and hold still,
5. The 'abc' will reappear in the textbox.
Actual Results:  
The value of 'abc' reappear in the textbox.

Expected Results:  
Pressing escape key shall has no effect in the textbox. 
It should be the same as other browsers.
It should not be considered as a feature because it could make both developer and user confuse on what is happening.

<body>
<input type="textbox" id="txtTest" onkeyup="testMe();" />
<script type="text/javascript">
function testMe(){
	value=document.getElementById('txtTest').value;
	if(value.length==3)document.getElementById('txtTest').value='';
}
</script>
</body>
Reproduced in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100216 SeaMonkey/2.0.4pre

Seems to me that the text immediately disappears after "Escape" is released, so I don't know that this is actually a problem.
Thanks for looking into this problem.

True. If holding the "escape" key, the text will re-appear, but releaseing the "escape" key, the text will disappears. At first sight, it shouldn't be a problem. 

However, unexpected problem occur, expecially compare with other browser.

example, I designed a script which work in this way, after user key in 3 characters, it will save the value automatically and clear the textbox. 
But when user type escape, the textbox reinput the text again, hence produce double entry. when user press "escape" several times, the value been saved several time. This is what I was facing (hence finally I choose opera for my project, instead of firefox). 

So, I believe, even though the text will be disappear after "escape" is released, it will still generate problem duing the "escape" key being pressed and value been re-input.
My attachment demonstrates the problem a little more clearly. Basically, if you focus into the textbox (via any means), and the first key you press is the ESC key on the keyboard, the "watermark" content will re-appear permanently.  If on the other hand, you press the arrow keys, or type some content in and then erase it, THEN pres the ESC key, the content does not come back. The attachment does not supply a DOC type, but that is not related (HTML5, XHTML Strict also trigger the bug).

I ran into this on Firefox 7, but not sure how far back the bug goes.

Hope this helps in tracking down the issue.
Attachment #563153 - Attachment mime type: text/plain → text/html
I encountered this as well, also in a watermark scenario. Here's the setup:

- OS X 10.8.4 / Firefox 22.0
- a <!DOCTYPE html> page
- a textbox <input type="text" maxlength="250" name="searchbox"></input> in the page

Here's what happens:
- a watermark text is programmatically set on page initialization
- Upon clicking or tabbing into the textbox, the watermark text is programmatically cleared
- With focus still on the textbox, pressing keyboard ESC re-instates the watermark text as the <input>'s value

It's a strange behaviour, not observed in Chrome 27 or IE10. I vote for removal unless there's an overriding reason for it to exist.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: