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

RESOLVED FIXED in mozilla2.0b11

Status

()

defect
RESOLVED FIXED
14 years ago
5 years ago

People

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

Tracking

(Depends on 1 bug, {regression, testcase})

Trunk
mozilla2.0b11
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

Reporter

Description

14 years ago
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>

Comment 2

14 years ago
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.

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Version: unspecified → 1.5.0.x Branch

Updated

11 years ago
Duplicate of this bug: 430929
Component: Location Bar and Autocomplete → Autocomplete
Product: Firefox → Toolkit
QA Contact: location.bar → autocomplete
Version: 1.5.0.x Branch → Trunk

Updated

10 years ago
Blocks: 531496
Assignee

Updated

8 years ago
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>)
Assignee

Comment 5

8 years ago
Posted 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)
Assignee

Updated

8 years ago
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-
Assignee

Comment 7

8 years ago
(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.
Assignee

Comment 8

8 years ago
Posted 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)
Assignee

Comment 9

8 years ago
Posted patch Patch v2.1Splinter 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+
Assignee

Updated

8 years ago
Attachment #505795 - Flags: approval2.0?
Assignee

Updated

8 years ago
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.
Assignee

Comment 11

8 years ago
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+
Assignee

Comment 13

8 years ago
(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.
Assignee

Updated

8 years ago
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.
Assignee

Comment 15

8 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/3f36d14effd1
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
Assignee

Updated

8 years ago
Target Milestone: mozilla2.0b10 → mozilla2.0b11
Assignee

Updated

8 years ago
Depends on: 598819
Assignee

Updated

8 years ago
Depends on: 651956

Updated

5 years ago
Duplicate of this bug: 531496

Updated

5 years ago
Blocks: 1025483
You need to log in before you can comment on or make changes to this bug.