388558 - 'change' event isn't dispatched if user selects input field value from the autocomplete list

Status: RESOLVED FIXED

(Toolkit :: Form Manager, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

testcase https://bugzilla.mozilla.org/attachment.cgi?id=256064 from 
bug 355367 can be used here too. Type 'c' to the first field and press enter.
Then reload the testcase and select 'c' from the autocomplete list and press tab.
I *think* we'd want to dispatch 'change' event in that case.
Problem is probably that formfillcontroller uses nsIDOMHTMLInputElement::value, 
which prevents 'change' event dispatch.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proposed patch + mochitest for the new setUserInput method

FormFillController must be able to set the value of the input in such way that
'change' event is dispatched. nsIDOMNSEditableElement::setUserInput doesn't
prevent event dispatch. That method is ofc only for privileged use, like
nsIDOMNSEditableElement::editor.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I think having this fixed in FF3 would be great.

Comment 4

[Jesse Ruderman]

Bug 359387 had 25 votes and several dups, but I duped it here because this bug has a patch.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Adding regression keyword. This used to work, afaik, in 1.5.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 272769 [details] [diff] [review]
proposed patch + mochitest for the new setUserInput method

Why not put the new function on nsITextControlElement instead? The only downside is that you can't write a mochitest for it.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 272769 [details] [diff] [review]
proposed patch + mochitest for the new setUserInput method

Opps, forgot to mark sr=me still.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> (From update of attachment 272769 [details] [diff] [review])
> Why not put the new function on nsITextControlElement instead?
If I remember right, I was thinking that having a scriptable method might be useful, for example for extensions or if formfillcontroller gets rewritten using JS.

Comment 10

[Fred]

Breaks my Seamonkey build (MOZ_SVG not defined).  Maybe that declaration for userInput can be moved in nsGkAtomList.h?

Comment 11

[Fred]

Here's the error...

nsHTMLInputElement.cpp: In member function 'nsresult nsHTMLInputElement::SetValueInternal(const nsAString_internal&, nsITextControlFrame*, PRBool)':
nsHTMLInputElement.cpp:937: error: 'userInput' is not a member of 'nsGkAtoms'

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Oh, sorry. Will fix asap.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Moved userInput out from #ifdef MOZ_SVG

Comment 17

[Pablo Greco]

I wanted to nominate this bug for branch, I don't have permission to flag wanted, so I'll try blocking.
The main reason is that this is a regression and the fact that the upgrade to firefox 3 will not be an easy option for many people, mainly because of old linux distributions and pango.
Let me know if there's anything I can do to help

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

blocking1.8.1.12 is impossible, maybe blocking1.8.1.13?

Comment 19

[Pablo Greco]

sorry about that, didn't have permission to blocking 1.8.1.13 :(

Comment 20

[jorilx]

I'm sorry, which version fixes this?

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

Currently trunk, so Firefox3.

Comment 22

[jorilx]

I see, thanks! Do you know if there are plans to merge the fix in 2.x?

Comment 23

[Daniel Veditz [:dveditz]]

Not blocking 1.8 release, but will look at approving a branch patch (merged, and including the seamonkey build-bustage fix).

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Pablo, can you, or will you have time to make the branch patch?

Comment 26

[naktinis]

Is it already fixed in beta 5?

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

yes

Comment 29

[naktinis]

According to "Bug 436255" which is marked as a duplicate of this bug, the problem is not fixed in beta 5. So maybe this ticket should be reopened or the "Bug 436255" is incorrectly marked as a duplicate. What do you think?

Comment 30

[Mark Tiefenbruck]

It was fixed for me in beta5, and your bug is identical to the one I submitted (except I always use the keyboard for everything). I suggest you try again with rc1.

Comment 31

[Glin]

naktinis:
Just tried in FF3 RC1, and it works fine, so this bug can remain closed. Thank you!

Comment 32

[naktinis]

Ok. By the way, could someone check a similar bug ("Bug 430929") which was filed more than month ago. The bug still has the unconfirmed status. The difference is that "Bug 430929" is about "input" event which doesn't fire when it should.