Closed Bug 735747 Opened 8 years ago Closed 8 years ago

Form autocomplete doesn't trigger oninput event

Categories

(Firefox for Android :: General, defect)

ARM
All
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 14
Tracking Status
firefox14 --- verified
firefox15 --- verified
blocking-fennec1.0 --- soft

People

(Reporter: martijn.martijn, Assigned: Margaret)

References

(Depends on 1 open bug, )

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

Attached file testcase
See testcase, steps to reproduce:
- Make sure you have some autocomplete suggestions available, if you haven't then put some text inside the input and press submit
- Then make sure the form autocomplete popups comes up, tap on one of the suggested values.

Expected result:
Input event fired, which shows up as text under the text input

Actual result:
No input event fired, nothing is showing up under the text input

Tested on current trunk build, Android 4.0.2, Samsung Galaxy Nexus.
To clarify, are you saying that when you tap a suggestion, the input doesn't get filled with the suggestion. This could be a problem with element.value, likely related to bug 735469.
No, the input does get filled with the suggestion, however, underneath the input, some text should appear like "event fired: input - input value: a" (if 'a' was the autocomplete suggestion that was tapped upon). That is the indication that an input event was fired, which currently doesn't seem to happen when autocomplete fills in the text in the input.

Btw, I noticed that the input event is fired twice, while typing a character with the virtual keyboard, so I filed bug 735806 for that.
Oh, I see. Does XUL fennec do this? I'm not sure what the expectation should be.
No, XUL Fennec doesn't seem to do this either, however desktop Firefox does this.
According to the spec, this event should fire when the user causes the input value to change, see: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#event-input-input
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → soft
Attached patch patch (obsolete) — Splinter Review
I really wonder why we chose to do it this way - I guess we were just copying XUL fennec? This is the way desktop Firefox does it, and this method does exactly what we want:
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/core/nsIDOMNSEditableElement.idl#56
Assignee: nobody → margaret.leibovic
Attachment #615437 - Flags: review?(mark.finkle)
Attached patch patchSplinter Review
We can also get rid of the .blur() hack in there (I confirmed that autocomplete works fine with that gone).
Attachment #615437 - Attachment is obsolete: true
Attachment #615437 - Flags: review?(mark.finkle)
Attachment #615440 - Flags: review?(mark.finkle)
Comment on attachment 615440 [details] [diff] [review]
patch

You are OK to land this patch
Attachment #615440 - Flags: review?(mark.finkle) → review+
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/mozilla-central/rev/b16ed4c13f5b
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Depends on: 749228
Everything works as expected on the latest Nightly and Aurora builds. Closing bug as verified fixed on:

Firefox 15.0a1 (2012-05-28)
Firefox 14.0a2 (2012-05-28)

Device: Galaxy Nexus
OS: Android 4.0.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.