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)
Tracking
()
People
(Reporter: dcg, Unassigned)
Details
Attachments
(1 file)
1.79 KB,
text/html
|
Details |
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)
Reporter | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
<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
Reporter | ||
Comment 3•21 years ago
|
||
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 → ---
Comment 4•21 years ago
|
||
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 ago → 21 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•21 years ago
|
||
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.
Description
•