Open
Bug 312162
Opened 19 years ago
Updated 2 years ago
Send onChange event some time after a keyboard change for <select size="1">
Categories
(Core :: Layout: Form Controls, enhancement)
Core
Layout: Form Controls
Tracking
()
NEW
People
(Reporter: ric.almeida, Unassigned)
References
Details
Attachments
(1 file)
2.72 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Ubuntu package 1.0.7) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Ubuntu package 1.0.7) There are webpages that rely on the onChange event being thrown when the user changes the selection of a drop-down. This work great when using the mouse, but using the keyboard makes the user think the page is broken as nothing happens until focus is lost... I believe the best solution would be to throw the onChange event after a given amount of time have passed since the change. That amount of time could be configured and have a default value of, let's say, 500ms. Disclamer: A similar bug is already posted in https://bugzilla.mozilla.org/show_bug.cgi?id=126379 but since I was "invited" to post a new bug request, here it is... Disclamer(2): After the onInput event is implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=312094) I would accept this bug to be marked WON'T FIX/WORKAROUND... Reproducible: Always Steps to Reproduce: 1.Go to http://www.kcfn.net/bible-memory.html?v=1 2.Change the verse using the keyboard Actual Results: Nothing happens until the component loose focus Expected Results: Change the page to the selected verse as it happens when the selection is made using the mouse
Comment 1•19 years ago
|
||
*** Bug 312167 has been marked as a duplicate of this bug. ***
Comment 2•19 years ago
|
||
Aaron, what do you think?
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.form-controls
Summary: Trow onChange event some time after a keyboard change → Send onChange event some time after a keyboard change
Version: unspecified → Trunk
Comment 3•19 years ago
|
||
I think this is a bad idea, worse than sending onchange immediately and worse than sending onchange only once the user has finalized the selection. Anything less than three seconds and keyboard-only users won't have a chance to read each item. Anything more than one second and the result of the onchange (page transition, form update) will be too separated from the item selection and will be confusing as a result. Also, using a timer on the order of seconds would violate a UAAG guideline, IIRC.
Reporter | ||
Comment 4•19 years ago
|
||
(In reply to comment #3) > I think this is a bad idea 90% of web users use IE and when visiting sites using the keyboard the onChange is fired immediatly. Never heard anyone complain about that. Now, I've heard/read lots of people complain about Mozilla don't having the same behaviour... What I'm proposing is that it's fired after the user has made it's selection and I believe that 750ms is more than enough, but it should be a configurated value...
Comment 5•19 years ago
|
||
Please read the rest of my comment, not just the first 7 words.
Reporter | ||
Comment 6•19 years ago
|
||
(In reply to comment #5) > Please read the rest of my comment, not just the first 7 words. I read all your comment and I understand your concern... But I still believe that 750ms is more than enough. But, if the timing is such an issue, and it's better not to send that send it too early/later, why not implement this with a devault value "never", thus having the same behaviour that current implementation, but users have the option to define some value (like 750ms ;) ). This way, by default Mozilla respects the W3C standard but users can choose what they think is best. Then we can open another bug request about what the defauld value should be...
Comment 7•19 years ago
|
||
I'm pretty sure the default will always be either "immediately" or "not until the selection is finalized", and given that, I don't see the point of adding a hidden pref for more awkward behaviors.
Reporter | ||
Comment 8•19 years ago
|
||
(In reply to comment #7) > I'm pretty sure the default will always be either "immediately" or "not until > the selection is finalized", and given that, I don't see the point of adding a > hidden pref for more awkward behaviors. The problem is how you know the seleccion is finalized. One option is when the component loose focus (what is implemented right now), the other is after a given time has passed and no change has been made. For me it's more akward the onChange being triggered only when component looses focus as when the selection is made with the mouse the component doesn't loose the focus and the event is triggered.
Reporter | ||
Comment 9•19 years ago
|
||
The attachment is based on http://www.dynamicdrive.com/dynamicindex1/combodescribe.htm and shows the inconsistent behaviour that mozilla has deppending on the size of the select box. Using the keyboard, change the values of the select boxes: - In the select box where only 1 item is shown onChange is only triggered after the component loose focus - In the select box with more items shown (2 in the case) onChange is triggered immediatly. I belive that they should behave the same, meaning, the select box with only one item should trigger the onChange event immediatly (or as also suggested in this bug report, after a given time).
Updated•19 years ago
|
Summary: Send onChange event some time after a keyboard change → Send onChange event some time after a keyboard change for <select size="1">
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•