Send onChange event some time after a keyboard change for <select size="1">

NEW
Unassigned

Status

()

Core
Layout: Form Controls
--
enhancement
12 years ago
4 years ago

People

(Reporter: Ricardo Almeida, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 years ago
*** Bug 312167 has been marked as a duplicate of this bug. ***
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
Blocks: 126379

Comment 3

12 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

12 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

12 years ago
Please read the rest of my comment, not just the first 7 words.
(Reporter)

Comment 6

12 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

12 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

12 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

12 years ago
Created attachment 199410 [details]
Incosistency Example

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

12 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">
You need to log in before you can comment on or make changes to this bug.