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

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Ricardo Almeida]

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

[Gilles Durys]

*** Bug 312167 has been marked as a duplicate of this bug. ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

Aaron, what do you think?

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Ricardo Almeida]

(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

[Jesse Ruderman]

Please read the rest of my comment, not just the first 7 words.

Comment 6

[Ricardo Almeida]

(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

[Jesse Ruderman]

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.

Comment 8

[Ricardo Almeida]

(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.

Comment 9

[Ricardo Almeida]

Attachment: 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).