Editing in Forms Undoes two steps at a time.

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Editor
P3
minor
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: hirata masakazu, Assigned: Akkana Peck)

Tracking

Trunk
mozilla0.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
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.

Comment 2

17 years ago
Adding jfrancis and myself to Cc list.
(Reporter)

Comment 3

17 years ago
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
Summary: Editing in Forms is broken. → Editing in Forms Undoes two steps at a time.

Comment 4

17 years ago
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?

Comment 5

17 years ago
really giving to joe
Assignee: beppe → jfrancis
Target Milestone: --- → mozilla0.9

Comment 6

17 years ago
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.
Severity: critical → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

17 years ago
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?

Comment 8

17 years ago
it really is a bug.  i suspect it's event or keybinding related, but I haven't 
investigated yet.

Comment 9

17 years ago
moving a bunch of 0.9 bugs to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 
Keywords: nsdogfood

Updated

17 years ago
Status: NEW → ASSIGNED

Comment 11

17 years ago
interestingly, I don't see this on Macintosh but I do see it on Windows.

Comment 12

17 years ago
*** 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.

OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 14

17 years ago
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.

Comment 15

17 years ago
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!!!
(Assignee)

Comment 16

17 years ago
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.)

Comment 17

17 years ago
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.

Comment 18

17 years ago
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?
Assignee: jfrancis → akkana
Status: ASSIGNED → NEW
(Assignee)

Comment 19

17 years ago
My fix for 57078 is in, so this should be fixed now.  Please test ...
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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.
(Reporter)

Comment 21

17 years ago
verifying fixed in 2001032808 trunk for MacOS.
Since Win32 and Linux builds have also been tested, I am marking this as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.