I suppose this is some kind of regression, but I am not sure which bug. While I am trying to copy/paste/delete/undo typing in forms of Bugzilla, a lot of weird behavior shows up. Reproducibility:Very much. For example, undo replaces the character before the undone block with something else. Another one is that if there is a long line in the Summary that requires scrolling to right, the input area in Description becomes impossible to edit: Caret position is weird, and delete/paste causes parts of text invisible, etc.
When submitting bugs, can you please report one issue per bug and include steps that can be used to reproduce the issue. It is also very important to know the platform you are on and which build you are using. I copy/paste all of the time in bugzilla and am not experiencing problems, so you will need to be explicit in what you mean by weird behavior. We do not see the scrolling problems either. We are not able to repro the undo problem that you reported.
Adding jfrancis and myself to Cc list.
Oh well, I believe the platform is clear. Anyway, I am deviding this one into two. This one is :In the text area of Form, Undo undoes two steps instead of one while Redo redoes one step only. 2000101904 and 2000101820
I believe Joe did some work in the undo/redo area -- assigning to him. Joe, wasn't there something about the context of inserting data and undo/redo?
really giving to joe
I am seeing this in 2000110108, but I don't think that this is a bug. Undo doesn't mean "undo only the exact last thing I did" or undo would undo every letter that you type one by one. If you paste something into bugzilla 4 times (for example) and press undo, 2 of the 4 go away. I don't think that this is really a bug, but I'll confirm it and let the Powers That Be decide about wontfix.
Oh, come on. If you pasted twice and hit undo, how would you expect Mozilla to work? Why is Mozilla undoing exactly two steps at a time and redoing one? Is there any other application that behaves like this? No user will appreciate this kind of behavior. If Mozilla can redo one step at a time, undo should match it. Otherwise, you have to undo and redo every time you want to undo one step. Is this a feature defined anywhere in the spec?
it really is a bug. i suspect it's event or keybinding related, but I haven't investigated yet.
moving a bunch of 0.9 bugs to 0.9.1
nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)
interestingly, I don't see this on Macintosh but I do see it on Windows.
*** Bug 71859 has been marked as a duplicate of this bug. ***
Changing OS/platform to all, since bug 71859 is on NT and I see this on Linux. Comment from bug 71859: It looks like nsEventListenerManager::HandleEvent() has 2 XBL key listeners that are both triggering calls into the the editor controller because it is the currently focused controller.
I mentioned in bug #71859 that the editor controller that handles cmd_undo is actually getting called twice ... so nsEditor::Undo() is getting called twice. I'm thinking we have a duplicate keybinding somewhere, so someone familiar with keybindings (akk? brade? anthonyd?) should look into this. brade mentioned to me that she's not seeing this on mac, but she has alot of keybinding changes in her tree.
I just tried CTRL-Z in my mac build and I see it undoing twice ... so brade *must* have it fixed already in her tree!!!
The reason Kathy and I have a lot of keybinding changes in our trees is that we're working on another bug concerning the fact that many keybindings are defined twice, in both XUL and XBL. If the bubble/capture is no longer being prevented by XUL, then the undo might be handled once by xul, then bubble/capture down to the widget level and be handled again by XBL. (The XBL binding *should* be the one that's used.) This is an old bug, but the one that was just marked a dup is a recent one, making me wonder if there might be a recent regression. (Doesn't sound like it belongs on jfrancis' plate; if it's a recent regression it might be a dup of a bug that Joki has.)
i can verify that this doesn't belong on my plate. :-) Nothing about the do/undo flow of control in the editor ever looks at whether someting is a form control. It is not possible for this to be an editor issue.
I just verified on Win32 that the keybinding cleanup patches in bug #57078 fix this bug. Reassign to akkana since she has bug #57078. Akkana, should we move this to mozilla0.8.1 like 57078?
My fix for 57078 is in, so this should be fixed now. Please test ...
seems to work for me with today's cvs build on Linux. I can't test D&D for unrelated reasons, but type,delete,type,undo does the right thing, whereas it did not use to.
verifying fixed in 2001032808 trunk for MacOS. Since Win32 and Linux builds have also been tested, I am marking this as verified.