Last Comment Bug 184761 - Send an event to form controls when they are restored
: Send an event to form controls when they are restored
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
-- enhancement with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2002-12-10 19:04 PST by John Keiser (jkeiser)
Modified: 2012-06-30 01:32 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image John Keiser (jkeiser) 2002-12-10 19:04:04 PST
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
Comment 1 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-12-10 19:50:26 PST
onchange is bad for <select>s which have an onchange that redirects the user
Comment 2 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-12-10 19:53:17 PST
i like onFill, where the event-object could contain information about why the
contorl was filled (autofill, restore, etc)
Comment 3 User image Johnny Stenback (:jst, 2002-12-10 20:24:12 PST
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?
Comment 4 User image John Keiser (jkeiser) 2002-12-10 20:25:45 PST
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.
Comment 5 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2002-12-10 21:37:45 PST
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
Comment 6 User image John Keiser (jkeiser) 2002-12-11 01:30:26 PST
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.
Comment 7 User image sheng han 2003-09-23 02:57:10 PDT
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!
Comment 8 User image Rémy Bach 2012-06-30 01:32:59 PDT
+1 for the autofill please! Even if it is a new onFill event, it's better than nothing!

Note You need to log in before you can comment on or make changes to this bug.