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
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.
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.
I think having this fixed in FF3 would be great.
Flags: blocking-firefox3? → blocking-firefox3-
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.
Attachment #272769 - Flags: superreview?(jst) → superreview?(jonas)
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: 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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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
blocking220.127.116.11 is impossible, maybe blocking18.104.22.168?
Flags: blocking22.214.171.124? → blocking126.96.36.199?
sorry about that, didn't have permission to blocking 188.8.131.52 :(
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: blocking184.108.40.206? → blocking220.127.116.11-
Pablo, can you, or will you have time to make the branch patch?
Is it already fixed in beta 5?
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.
naktinis: 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.
You need to log in before you can comment on or make changes to this bug.