Closed Bug 320462 Opened 19 years ago Closed 13 years ago

input event (oninput) not fired by autocomplete and list selection (from <datalist>)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b11

People

(Reporter: bugzilla.x.jsd, Assigned: mounir)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 2 obsolete files)

testcase from comment 0
730 bytes, text/html
Details
Patch v2.1
4.32 KB, patch
smaug
: review+
sicking
: approval2.0+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When running under Firefox 1.5:
If you enter text into an input text field via autocomplete,
the input event does not fire.

Firefox 1.0.7 did generate an input event.


Reproducible: Always

Steps to Reproduce:
Load this HTML page and follow the instructions:

<html>
<body>
<form name='f'>
Instructions:<br>
Enter several characters into the input field, then press Enter to clear/submit.<br>
Now type the first letter from before, this should bring up the autocomplete list.<br>
Select the item from the autocomplete list.  You will see that 1.0.7 generates<br>
an input event for this but 1.5 does not.<br><br>
	Enter input: <input name='inp' type='text'><br>
	Events: <br>
	<textarea name='out' rows='20' cols='60'></textarea>
	</form>
</body>
<script>
document.f.inp.addEventListener('input', onInput, true);
function onInput(evt)
{
	document.f.out.value += "value is now: " + document.f.inp.value + "\r\n";
}
</script>
</html>
Confirmed using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051108 Firefox/1.5.

Adding "oninput" to the summary because it's easier to search for.
Component: Form Manager → Location Bar and Autocomplete
QA Contact: form.manager → location.bar
Summary: input event not fired by autocomplete → input event (oninput) not fired by autocomplete
I can confirm on 1.5.0.1. Also, can someone with privs set:
 OS: All
 Version: 1.5.0.x branch


This is problematic for DHTML web applications like the Oracle Web Access Client. We need to know right away when an input field has been updated (e.g., for an incremental search UI).

Mozilla's "oninput" event is very helpful in this regard, but this bug means there is no 100% reliable way to know immediately when a field is changed. Afaict, no content events are fired when an autocomplete item is chosen.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Version: unspecified → 1.5.0.x Branch
Component: Location Bar and Autocomplete → Autocomplete
Product: Firefox → Toolkit
QA Contact: location.bar → autocomplete
Version: 1.5.0.x Branch → Trunk
Blocks: 531496
Component: Autocomplete → DOM: Core & HTML
Product: Toolkit → Core
QA Contact: autocomplete → general
Hardware: x86 → All
Summary: input event (oninput) not fired by autocomplete → input event (oninput) not fired by autocomplete and list selection (from <datalist>)
Attached patch Patch v1 (obsolete) — — Splinter Review 
I wonder if we could take this in Gecko 2.0...
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #505788 - Flags: review?(Olli.Pettay)
Whiteboard: [needs review]
Ah, this is very much related to Bug 388558.

Does the patch guarantee that there are no two input events dispatched.
Or does the input event get dispatched currently only when user edits the value?
(I guess so)

canbubble/cancelable flags are anyway different in the patch to the event dispatch
in nsTextControlFrame::FireOnInput
Attachment #505788 - Flags: review?(Olli.Pettay) → review-
(In reply to comment #6)
> Ah, this is very much related to Bug 388558.
> 
> Does the patch guarantee that there are no two input events dispatched.

Hmmm, I don't see how.

> Or does the input event get dispatched currently only when user edits the
> value?
> (I guess so)

An event would be send whenever a value would be selected. I don't think we have to check that the value actually changed. We already can't guarantee that with copy-pasting actions.

> canbubble/cancelable flags are anyway different in the patch to the event
> dispatch
> in nsTextControlFrame::FireOnInput

input event is a "simple event" so it can't bubble and should not be cancelable according to HTML WHATWG specs. If nsTextControlFrame::FireOnInput does something else, this should be fixed.
Attached patch Patch v2 (obsolete) — — Splinter Review 
Oups, you are right, it has to bubble.
I promise, I will try to learn how to read.
Attachment #505788 - Attachment is obsolete: true
Attachment #505793 - Flags: review?(Olli.Pettay)
Attached patch Patch v2.1 — — Splinter Review 
And cancelable has requested on IRC. With tests.
Attachment #505793 - Attachment is obsolete: true
Attachment #505795 - Flags: review?(Olli.Pettay)
Attachment #505793 - Flags: review?(Olli.Pettay)
Attachment #505795 - Flags: review?(Olli.Pettay) → review+
Attachment #505795 - Flags: approval2.0?
Whiteboard: [needs review] → [needs approval]
I think we could take this to FF4, but the patch causes any regressions, it 
should be just backed out, and re-landed after FF4.
I've open bug 627726 to make the input event not cancelable.
Comment on attachment 505795 [details] [diff] [review]
Patch v2.1

Please don't file a separate bug to fix a problem in this patch. Just fix the problem here directly and pass PR_FALSE for the cancelable argument.
Attachment #505795 - Flags: approval2.0? → approval2.0+
(In reply to comment #12)
> Comment on attachment 505795 [details] [diff] [review]
> Patch v2.1
> 
> Please don't file a separate bug to fix a problem in this patch. Just fix the
> problem here directly and pass PR_FALSE for the cancelable argument.

It's not a problem in this patch. We make all input event cancelable for the moment. For consistency, this one is cancelable too. The opened bug is to make them not cancelable as required per spec and as Presto and Webkit do.
Whiteboard: [needs approval]
Just to clarify, I explicitly asked our implementation to behave consistently,
and I wanted to reduce regression risk at this point, so no change to the cancelable.
Pushed:
http://hg.mozilla.org/mozilla-central/rev/3f36d14effd1
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
Target Milestone: mozilla2.0b10 → mozilla2.0b11
Depends on: 598819
Depends on: 651956
Blocks: 1025483
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: