Closed Bug 388558 Opened 13 years ago Closed 13 years ago

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


(Toolkit :: Form Manager, defect)

Not set





(Reporter: smaug, Assigned: smaug)



(Keywords: regression)


(1 file)

testcase 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.
Assignee: nobody → Olli.Pettay
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
Attachment #272769 - Flags: superreview?(jst)
Attachment #272769 - Flags: review?(jst)
I think having this fixed in FF3 would be great.
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
Blocks: 359387
No longer blocks: 359387
Duplicate of this bug: 359387
Bug 359387 had 25 votes and several dups, but I duped it here because this bug has a patch.
Adding regression keyword. This used to work, afaik, in 1.5.
Keywords: regression
Attachment #272769 - Flags: superreview?(jst) → superreview?(jonas)
Duplicate of this bug: 394411
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 on attachment 272769 [details] [diff] [review]
proposed patch + mochitest for the new setUserInput method

Opps, forgot to mark sr=me still.
Attachment #272769 - Flags: superreview?(jonas) → superreview+
(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.

Attachment #272769 - Flags: review?(jst) → review+
Attachment #272769 - Flags: approval1.9?
Attachment #272769 - Flags: approval1.9? → approval1.9+
Breaks my Seamonkey build (MOZ_SVG not defined).  Maybe that declaration for userInput can be moved in nsGkAtomList.h?
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'
Oh, sorry. Will fix asap.
Moved userInput out from #ifdef MOZ_SVG
Closed: 13 years ago
Resolution: --- → FIXED
Duplicate of this bug: 398974
Duplicate of this bug: 408070
Duplicate of this bug: 411247
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
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
Flags: blocking1.8.1.12?
blocking1.8.1.12 is impossible, maybe blocking1.8.1.13?
Flags: blocking1.8.1.12? → blocking1.8.1.13?
sorry about that, didn't have permission to blocking :(
I'm sorry, which version fixes this?
Currently trunk, so Firefox3.
I see, thanks! Do you know if there are plans to merge the fix in 2.x?
Not blocking 1.8 release, but will look at approving a branch patch (merged, and including the seamonkey build-bustage fix).
Flags: blocking1.8.1.13? → blocking1.8.1.13-
Pablo, can you, or will you have time to make the branch patch?
Duplicate of this bug: 419828
Is it already fixed in beta 5?
Duplicate of this bug: 436255
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?
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.
Just tried in FF3 RC1, and it works fine, so this bug can remain closed. Thank you!
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.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.