Closed Bug 228850 Opened 21 years ago Closed 21 years ago

onkeydown only produces double entries *except* when process is interrupted with alert

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1572

People

(Reporter: dcg, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

the issue concerns catching keys via the onkeydown handler.

In IE5+ it works fine but in Moz 1.6a+b (& Firebird 0.7+) it behaves most
peculiar. The 'offensive' code is in the attached.

The weird thing lies in the alert box preceded by // **.
* function textboxReplaceSelect *
If the alert is active the code works perfect. No key duplication in the textbox
on the screen.
Insert the comment ()i.e. take out the alert) and one gets two characters
instead of one.
It almost looks like something 'shoots through' because (to make things
worse) the last alert shows a singular entry as well.
Summarized: onkeydown produces double characters unless interrupted by an alert
message to temporarily hold the process.

Reproducible: Always

Steps to Reproduce:
1. Just use the attached code (without the alert) to see the error
2. Uncomment the alert and look at the result on the screen


Actual Results:  
After step 1 there are 2 characters on the screen
After step 2 there is just 1 character on the screen

Expected Results:  
There should always just be 1 character (as only 1 character was pressed)
<input type="text" value="" id="txtSearch" onkeypress="return showDown(this,
event);" />

If you replace "onkeydown" with "onkeypress", then the script works as it
should. I'm resolving this bug as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
With all due respect but should is it not totally irrelevant whether onkeydown
OR orkeypress is utilized in this particular case? As onkeydown is more widely
supported *and* also pretty standard I do not understand the reasoning behind
using onkeypress.
Unless there *is* a valid reason for the code to work properly WITH a stop via
the alert message.
It strikes me as rather strange that taking out the alert stuffs up the code.
This to me implies that something is not as it should and thus I *do not*
understand the 'invalidation' of the submission.

I might agree to the onkeypress suggestion but that still leaves the onkeydown
issue *unresolved* for it does not work as it should. Or is this assumption
incorrect?

TIA
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I understand your point. It seems that onkeydown="return false" doesn't cancel
the key anything, but I've investigated this bug further:

This bug is essentially the same as Bug 28323:
> [DOM] onkeydown="return false" doesn't cancel the key in INPUT TYPE="text"

Which was duped as Bug 1572 (specifically, see Bug 1572 comment #30).
> Key events are not cancellable

Which is resolved as WONTFIX.

*** This bug has been marked as a duplicate of 1572 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
Fair enough.
I'm not sure I fully grasp the reasoning yet but I'll guess a workaround will
just have to cover the situation at hand.

Thx for the effort anyway.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: