Closed Bug 21602 Opened 20 years ago Closed 20 years ago

[DOGFOOD] ^V in the urlbar pastes twice: key events not cancelled

Categories

(Core :: XUL, defect, P2, critical)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: saari)

References

Details

(Whiteboard: [PDT+] Checked in more stuff, missed file, think it is really fixed now)

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).
OS: Linux → All
Hardware: PC → All
[Changing Platform/OS to 'All'; I'm not seeing this 100% of the time, but it's
also happening on Mac OS.]
Whiteboard: [PDT+]
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.
Whiteboard: [PDT+] → [PDT+] needs estimated fix date here
These aren't in the frame, they're dom event handlers in
editor/base/nsEditorEventListeners.cpp.
Priority: P3 → P2
Target Milestone: M12
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.
Depends on: 20519
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Just checked in fix
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
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 ago20 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.
Status: RESOLVED → VERIFIED
verified
You need to log in before you can comment on or make changes to this bug.