Closed
Bug 158071
Opened 23 years ago
Closed 21 years ago
Input undo/redo buffers cleared after Javascript changes to input values
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: leonard, Assigned: martijn.martijn)
References
()
Details
(Whiteboard: [jk-little])
Attachments
(2 files)
235 bytes,
text/html
|
Details | |
928 bytes,
patch
|
bryner
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020715
BuildID: 2002071508
I noticed this implementing a rich text-edit control (see URL), but this problem
affects any input manipulated by JavaScript.
Firstly, a Javascript input.value change is captured by the undo buffer, and
secondly, if an input.value is called, it will actually clear the undo/redo
buffer for that input.
That's bad.
Reproducible: Always
Steps to Reproduce:
1. Go to a page with an input/textarea
2. Type some stuff, delete some stuff in input/texarea. Make sure the undo/redo
buffer is working
3. Type: 'javascript:document.getElementsByTagName("input")[0].value = "foo";
void 0' in the URL bar (replace input w/ textarea if it's a textarea)
4. Try undoing the change or any of your previous changes in that input/texarea.
You can't.
Actual Results: Input/textarea's value is 'foo'. This change cannot be undone.
Expected Results: Mozilla should allow that action to be undone, and should not
clear the undo/redo buffer. A javascript value change should be equivalent to a
single typing action's change.
IE has the expected (correct) behavior.
![]() |
||
Comment 1•23 years ago
|
||
would be nice.....
Assignee: rods → jkeiser
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Updated•22 years ago
|
Priority: -- → P3
Whiteboard: [jk-little]
Target Milestone: --- → Future
Assignee | ||
Comment 3•21 years ago
|
||
I don't know anything of c, but isn't this explicitly programmed this way here:
http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsTextControlFrame.cpp#2159
So by removing these lines which disable/enable undo, the bug would be fixed
(not if I'm wrong off course, then sorry for the spam)
Assignee | ||
Comment 4•21 years ago
|
||
Assignee | ||
Comment 5•21 years ago
|
||
Just deleting these lines seem to make this work in my homebrewn build.
Assignee | ||
Updated•21 years ago
|
Attachment #145575 -
Flags: review?(bryner)
Comment 6•21 years ago
|
||
Comment on attachment 145575 [details] [diff] [review]
Patch to turn on again the undo/redo buffers
Seems ok, and I can't find any trail that tells me why the code was written
this way. Over to dbaron for a second opinion though.
Attachment #145575 -
Flags: superreview?(dbaron)
Attachment #145575 -
Flags: review?(bryner)
Attachment #145575 -
Flags: review+
Attachment #145575 -
Flags: superreview?(dbaron) → superreview+
Assignee | ||
Comment 7•21 years ago
|
||
So the patch got review+ and superreview+. Isn't it ready then to be checked in?
(Sorry for sounding so ignorant)
![]() |
||
Updated•21 years ago
|
Assignee: core.layout.form-controls → m.wargers
![]() |
||
Comment 8•21 years ago
|
||
(In reply to comment #7)
> So the patch got review+ and superreview+. Isn't it ready then to be checked in?
It is, but you need to get someone to do that. Note that dbaron and bryner are
not cced on the bug, so they didn't see that question.
I just checked in the patch to the 1.8a trunk.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•21 years ago
|
||
Could this get in the aviary branch, please? I don't think there is any risk
with this patch and with this patch, Firefox would be more friendly to
bb/Blogger forms.
Flags: blocking-aviary1.0?
Updated•21 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 10•20 years ago
|
||
*** Bug 274395 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•