Open Bug 317757 Opened 19 years ago Updated 2 years ago

onchange, onblur do not detect Shift key

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows XP
defect

Tracking

()

UNCONFIRMED

People

(Reporter: danswer, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051020 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051020 Firefox/1.6a1

If I have a select element with an onchange or onblur handler, I cannot detect whether the shift key has been held down upon the event firing.  On IE, shift key state works as expected.  Also, when the onclick handler fires, I can detect the keyboard state.

It seems to me I've seen a discussion of this problem, but I wasn't able to find it.  Of course if the onchange is done with a mouse, then by saving the shiftKey state when the onclick fires, I could get that state, but this approach is pretty sketchy.  And I would need to know the appropriate keyboard event counterpart to be checking for.

Csaba Gabor from Vienna

Reproducible: Always

Steps to Reproduce:
See attachment.  Every time you hold the shift key down for the events listed the shift key down should be detected, but in FF it only happens for the third of the three drop downs.
Why should onblur or onchange detect the shift key?
Those are not keyboard or mouse events.
Well, Mozilla's own documentation says that is what it should do:
http://www.mozilla.org/docs/dom/domref/dom_event_ref.html

It lists event properties and for shiftKey has:
Returns a boolean indicating whether the <shift> key was pressed when the event was fired.

There is no mention of "keyboard" or "mouse" events.  Ultimately (ignoring the documentation), it is a question of religion.  I view the state of the mouse and keyboard as system attributes that should be trivial to query.  In fact, I would go so far as to say that it should be possible to check for these at any time through a 'nonevent' event.

One could also take an opposing view that this type of information is specific to only certain types of events and the corresponding properties are not defined in other situations.  If a person really wants to know what the state is at that time, they're just going to have to keep track of it by trapping for all events where such information might come into play.

Csaba
Assignee: events → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
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: