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)
Core
Layout: Form Controls
Tracking
()
NEW
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)
Comment 3•22 years ago
|
||
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?
Reporter | ||
Comment 4•22 years ago
|
||
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
Reporter | ||
Comment 6•22 years ago
|
||
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.
Reporter | ||
Updated•22 years ago
|
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!
Updated•15 years ago
|
QA Contact: tpreston → layout.form-controls
Updated•13 years ago
|
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!
Comment 10•6 years ago
|
||
No assignee, updating the status.
Comment 11•6 years ago
|
||
No assignee, updating the status.
Comment 12•6 years ago
|
||
No assignee, updating the status.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•