Last Comment Bug 184761 - Send an event to form controls when they are restored
: Send an event to form controls when they are restored
Status: ASSIGNED
:
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
:
Mentors:
Depends on:
Blocks:
  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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description 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
value).
Comment 1 Jonas Sicking (:sicking) 2002-12-10 19:50:26 PST
onchange is bad for <select>s which have an onchange that redirects the user
Comment 2 Jonas Sicking (:sicking) 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 Johnny Stenback (:jst, jst@mozilla.com) 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 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 Jonas Sicking (:sicking) 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 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 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 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.