Closed Bug 21602 Opened 20 years ago Closed 20 years ago
[DOGFOOD] ^V in the urlbar pastes twice: key events not cancelled
xulkey-v in the url bar pastes twice. The key event is handled through the XUL inputBindings and editor controller, but then the event isn't cancelled and it's passed through to the hardwired editor key listeners where it's handled again, so the user sees two pastes of the same text.
Doh...I can't reproduce this using this morning's Mac OS build, or yesterday's Linux build. I can reproduce it on this morning's Windows build. Akkana, should the 'OS' be changed to Windows? Do you think this should be an M12 bug?
I saw this on both yesterday's and today's Linux build, too, but only with alt-V paste, not with middle-mouse paste (it's a key event issue, doesn't happen for mouse events). I think it should be an M12 bug. It's a regression and makes paste very hard to use.
Summary: ^V in the urlbar pastes twice: key events not cancelled → [DOGFOOD] ^V in the urlbar pastes twice: key events not cancelled
Tossing onto PDT radar to request consideration for M12 (or at least M13).
[Changing Platform/OS to 'All'; I'm not seeing this 100% of the time, but it's also happening on Mac OS.]
Pretty sure this is a dup....sujay? Putting on PDT+ radar for now.
Wait a minute, didn't mjudge remove the hardwired ender key event handlers in the frame? I'm confused.
These aren't in the frame, they're dom event handlers in editor/base/nsEditorEventListeners.cpp.
targetting p2 for m12 (since we don't know when it will close). There is no way this bug should be marked critical severity, that's for crashes, bad leaks, and data loss.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] needs estimated fix date here → [PDT+] fix in hand, must get review
It helps if ender actually returns the proper event states back out of its wonderland and if someone actually listens to them before dispatching back into ender's second listener. (why does ender have two event listeners?) Need to confer with joki that this is the right fix, but I'm pretty confident in it.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Just checked in fix
I updated but it still happens. To reproduce: Start a browser window. Copy some plaintext in another app. Slowly (slower than double-click speed), click in the urlbar, in the content area, in the urlbar, and in the urlbar (somewhere in the middle, not the beginning or end) to set the focus there. Type xulkey-V to paste. Result: the text is pasted twice. One of those times is from nsEditorEventListeners (I have a printf there in my local tree). saari has seen this and is hot on the trail.
Clearing FIXED resolution due to reopen.
Whiteboard: [PDT+] fix in hand, must get review → [PDT+] Checked in more stuff, missed file, think it is really fixed now
Akkana, I checked in a fix after I talked to you yesterday, I think it was nsGfxTextControlFrame.cpp but check cvs to make sure. That *should* fix it, I tried the multi- click dance you showed me and that worked ok. Give it a try.
final m12 candidates are spinnning now. moving to m13. if we fall off track and need to respin m12 for some yet unknown reason we can consider this if you get a fix in hand.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12
control v in the url bar looks like it is working for me (paste only one time) in the 12/16 win32 build. marking fixed so it will get some testing. reopen if some one sees a problem.
Although I defer to Claudius for verification, I can't personally reproduce this using today's M12 builds on Win32/Linux & Akkana's 1999-12-15 steps to reproduce.
You need to log in before you can comment on or make changes to this bug.