62753 - [FIX][MF]OnChange events are not being sent at the right times for selects

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[[e-mail]]

1. Drop the Translate combo box down.
2. Hit F for French to English.
3. Click on the background.
4. Drop the Translate combo box down.

Expected result: French to English is highlighted, as this appears as the value.

Actual result: English to French is highlighted.

Additional information: English to French is submitted!

Comment 1

[rods (gone)]

Works fine for me on WinNT.

The bug is that if the <shift> is held down it doesn't work. Is that the bug you 
are seeing? because when I press just 'f' the combobox goes to the correct item 
and it does translate from French to English

Comment 2

[[e-mail]]

It works fine if the combo box is not dropped down when you hit F.
Interestingly, I notice that if you tab to the resolution combo box in Bugzilla,
then press F, the change event gets sent to JavaScript (the radio button changes).
But if you drop down the combo box and press F then it doesn't.
It looks as the value has changed but it hasn't.

Comment 3

[rods (gone)]

What exactly is the bug?

Comment 4

[[e-mail]]

I'll try to explain again. I've changed the summary to add the word "dropped".

Below this comments box is a set of radio buttons, one of which is labelled
"Resolve bug, changing resolution to" and a combo box with the event handler
ONCHANGE="document.changeform.knob[1].checked=true"
which makes the problem easier to see.

Select "FIXED" from the combo box using the mouse and the button gets checked.
(Check another button so that you can retest)
Without dropping the dropdown, changing with the keyboard checks the button.
(Check another button so that you can retest)
Now drop the combo box but try to change it with the keyboard.
The combox value appears to change. However the button does not get checked.
If you drop the combo box again you will notice the previous value highlighted.
If you sumbit the form you will notice the previous value submitted.

Comment 5

[rods (gone)]

Attachment: simplified test

Comment 6

[rods (gone)]

It seems to work fine for me. If I give focus to the "fixed" combobox and press 
"L" for LATER the combobox shows "LATER" and the "fixed" radiobutton is 
selected. If I then press "Commit" it echoes that the radiobutton's value is 
"resolve" and the combo is LATER. 

Comment 7

[[e-mail]]

If the combobox has focus but is not dropped, then I agree that's OK.
But of course you have to remember what the options are.
If you drop the combobox so that you can see them, the error occurs.
This is using build 2000122204 but I'll download an update tonight.

Comment 8

[rods (gone)]

Neil, that is the part I don't understand. If drop down the list and select one 
of the items with the arrow keys or by pressing the first letter, it goes to 
that item. If I click away from the drop down (outside the dropdown) that 
cancels the new selection. If I press return, that selects the item and it works 
as advertised.

So I still don't understand what the bug is or what is not working, please 
explain again.

Comment 9

[[e-mail]]

Changing summary to reflect new understanding of problem.
When you drop the combo box and change the selection with the keyboard,
the selection updates in the main box as well as in the dropdown.
However when you cancel the combo box the selection should revert.
What happens at present is:
Cancelling with ESC reverts the selection but triggers the onchange event.
Cancelling by clicking outside the list does not revert the selection.

Comment 10

[rods (gone)]

Here is what I am seeing in Nav 4.x:
1) <esc> doesn't cancel the drop down
2) Arrow Keys with Dropdown "down" - 
   selects a new item, updates display, fires onchange event, 
   rolls up dropdown
3) Arrow Keys with Dropdown "up" - 
   selects a new item, updates display, fires onchange event
4) Press the first letter with Dropdown "down" - 
   selects new item and updates display, then
   a) When return is pressed -> fires  onchange
   b) When clicking outside dropdown -> reverts back to previous item, 
      fires onchange
5) Press the first letter with Dropdown "up" - , 
   selects the new item, updates display, 
   but doesn't fire onchange event until the select loses focus

IE 5.0 (WinNT):
1) <esc> cancels dropdown without firing onchange and reverts
2) Arrow Keys with Dropdown "down" - 
   selects a new item, updates display, then
   a) When return is pressed -> fires onchange
   b) When clicking outside dropdown -> fires onchange
3) Arrow Keys with Dropdown "up" - 
   selects a new item, updates display, fires onchange event
4) Press the first letter with Dropdown "down" - 
   selects new item and updates display, then
   a) When return is pressed -> fires  onchange
   b) When clicking outside dropdown -> fires  onchange
5) Press the first letter with Dropdown "up" - , 
   selects the new item, updates display, fires onchange (immediately)


Mozilla
1) <esc> cancels dropdown without firing onchange and reverts
2) Arrow Keys with Dropdown "down" - 
   selects a new item, updates display, then
   a) When return is pressed -> fires onchange
   b) When clicking outside dropdown -> retains newly selected value, 
      does NOT fires onchange (** BUG **)
3) Arrow Keys with Dropdown "up" - 
   selects a new item, updates display, fires onchange event
4) Press the first letter with Dropdown "down" - 
   selects new item and updates display, then
   a) When return is pressed -> fires  onchange
   b) When clicking outside dropdown -> fires does NOT onchange (** BUG **)
5) Press the first letter with Dropdown "up" - , 
   selects the new item, updates display, fires onchange (immediately)

Note: Mozilla has has a known bug of not updating the combobox display 
until after the dialog goes away from the onchange event.

The other question is: Should Mozilla's behavior be like IE or like Nav 4.x, I 
think the IE behavior makes a little more sense for these behavior patterns.

Comment 11

[[e-mail]]

Many pages perform major actions from the onchange event of a combo box. With
Communicator it is difficult to use the keyboard because you can't scroll
through without firing onchange events. In IE you just drop the combo box with
Alt+Up or Alt+Down first. Speaking of which, is there an RFE for this yet?

Comment 12

[rods (gone)]

There is a bug on the Alt-Up/Down and I did a litle work, but event bubbling got 
in my way and I couldn't explain why. I am changing the summary again, because 
it isn't just the cancelling behavior that is work.

I really think the IE sends onchange events makes selects more usable than the 
way Nav 4.x does it. I'll try to find more info on this in the spec.

Comment 13

[Vladimir Ermakov]

QA Contact Update

Comment 14

[rods (gone)]

Attachment: patch

Comment 15

[rods (gone)]

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

Comment 16

[Fabian Guisset]

lxr shows the file layout/html/forms/src/nsGfxListControlFrame.cpp contains four
calls to ListWasSelected, and your patch doesn't address those... is it on purpose?

Comment 17

[rods (gone)]

I am no longer keeping it up to date. Instead of getting it to work, we will be 
moving over to XBL-based controls in the future.

Comment 18

[Johnny Stenback (:jst)]

Rod, could you please cvs remove those unused files? If you need them back you
can always get the files back from cvs...

Comment 19

[rods (gone)]

I'll do it when I check this fix in.

Comment 20

[Eric Pollmann]

r=[e-mail]

Comment 21

[Marc Attinasi]

sr=attinasi

Comment 22

[rods (gone)]

fixed

Comment 23

[Vladimir Ermakov]

Verifying on build 2001-04-10-04-trunk windows 98