I just accidentally clicked the Reset button on a bugzilla form and all my work was lost. If I could have gone to edit>undo i would have been very happy.

This won't happen until after we move Reset from frames to content. Adding dependency. BTW, we'll keep this in mind when we move values over and design the values such that they *can* be stored and restored.

reassinging to new owner of form submission

I'd agree wholeheartedly with this idea, if it weren't for the fact it would be a security problem. For example ... There's a kiosk at the University of Canterbury Library, running Mozilla 4.x, open on a Web page which lets you transfer money from your computer services account to your library account and vice versa. The idea is that when you've finished, you click the `Reset' button so that no-one can mess around with your account, or use fancy bookmarklets to read your password from the form field, or whatever. If a reset could be Undone, it would blow a big hole in this process.

*** Bug 117691 has been marked as a duplicate of this bug. ***

this would be a very wellcome enhancement i suppose setting milestone

Storing all that info in the undo list would get expensive, wouldn't it? At any rate, whoever implements this finally should keep in mind that this should only happen when the user hits the Reset button, not every time JS calls .reset() or we call reset internally ... and we do that frequently on individual controls. This should just be a matter of storing a hash from content pointers to values (probably nsISupports or something). For select it gets somewhat tricky, but it could be as simple as storing an array or a comma-separated list of indices (probably a comma-separated string will be more space-efficient, which is really the trick here).

My solution is a user style sheet rule: input[type="reset"], button[type="reset"] { display:none }

mpt: passwords should be omitted from the undo-reset data. That would be similar to the solution to bug 65947, "form password is remembered when hitting back button" (fixed).

*** Bug 239668 has been marked as a duplicate of this bug. ***