Open Bug 184761 Opened 22 years ago Updated 2 years ago

Send an event to form controls when they are restored

Categories

(Core :: Layout: Form Controls, enhancement)

enhancement

Tracking

()

People

(Reporter: john, Unassigned)

Details

We should send an event to a form control when we restore its value, rather than
change it without any way to tell the web developer.  It is bad enough that we
*do* this, dumping values into their controls--web developers don't generally
code for the back button in my experience--but it is criminal that there is no
way for the developer to react to it when they *do* find out about it.

onChange is one major candidate, but might cause compatibility problems.  On the
other hand, it could make the existing web work a ton better, especially for the
common case where one dropdown being changed fills in values for the next
dropdown, etc.

onRestore is another possibility, or maybe onFill (autofill should do this as
well, onfill would be for anything where the user agent fills the control with a
value).
onchange is bad for <select>s which have an onchange that redirects the user
i like onFill, where the event-object could contain information about why the
contorl was filled (autofill, restore, etc)
Let's not define new onFoo event handlers on DOM nodes, they're old school, they
don't scale, and so on. If we do this, let's keep this at the DOM Level 2 Event
model level, IOW, to get one of these events, you must do
addEventListener("fill", ...) or whatever we choose to call the event. Does IE
have anything similar to this? If so, let's try to mimic what it does, if not,
we'll haveto think about the best aproach here. Do we need support for this in
markup (i.e. <input type=... onfill=...>), or is it enough to have the ability
to add listeners for this event from script?
It's sufficient to have DOM listeners, but last I read the code, we can get
onfill for nearly free, and it would help web developers a good deal.  I think
it's a good rule to say: if a developer is doing onchange (a very convenient
method), they are likely to want to do onfill as well.
Status: NEW → ASSIGNED
At what time will this event be fired? If we don't have an onFill attribute we
must allow the developer to attach an eventlistener before the event is fired
An excellent point.  onfill will be called *as soon as* elements are restored,
which in Netscape is before any JavaScript has a chance to execute.  Therefore
"onfill" becomes necessary.
Severity: normal → enhancement
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
what about this bug now? I am a developer that waiting for this change for a
long long time (since 1.0).

Thanks for the hard work!
QA Contact: tpreston → layout.form-controls
Assignee: john → nobody
OS: Windows XP → All
Priority: P3 → --
Hardware: x86 → All
Target Milestone: mozilla1.4beta → ---
+1 for the autofill please! Even if it is a new onFill event, it's better than nothing!
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.