Closed pkaminski closed 8 years ago
Hi @pkaminski , so there could be two approaches to this:
What do you think?
I don't know why you need to delay the pasteText
event so I can't tell what would be a good solution. I don't think you can avoid firing the blur
or add extra parameters to it (unless you intercept it in the capturing phase? that might work). Even just adding an extra attribute to the textarea
(e.g., pasteInProgress = true
) would be enough for me -- anything that will tell me that focus was lost automatically, and will come back automatically soon.
@pkaminski I managed to prevent "fake" blur/focus event from happening, you can see console logs on the demo page. And you need to put you event handler "after" invoking paste.js in order to make it work. I haven't yet pushed a release because currently I'm downloading an Edge VM to try to validate the recent changes on Microsoft Edge. The delaying of pasteText
is due to solve problems for #23 . So if you can grab the latest code, you can help me verify whether it works.
@pkaminski You can review the changes here e2039c2e4ad802788a26479549917c90b24144d1 , and this issue is only applicable for Firefox && IE11 (and possibly Edge) now.
I tried the version from HEAD and the blur
-prevention appears to be working as advertised. However, there's another new issue: after pasting text in Firefox (v43 on Win10), the visible cursor jumps two lines below the bottom line of the textarea even though the insertion point is positioned right after the pasted text (as shown by typing something). The visible cursor's position is outside the bounds of the text content and it couldn't be positioned there by clicking, so this is really weird. This doesn't happen with 0.0.14.
@pkaminski , This is really an issue where firefox didn't correctly handle prevention of propagation on capture-phase event, I actually googled a similar issue ( https://bugzilla.mozilla.org/show_bug.cgi?id=509376 ) with another event. Meanwhile I let go the onfocus/onblur events on capture-phase to eliminate this issue. It wouldn't be a problem if you are using jQuery to bind your events (on the bubbling-phase).
I was wrong it's not Firefox's bug but just me meddling with those two events on wrong target (document
). But the solution would be the same. @pkaminski Can you check out the HEAD version?
I checked against HEAD (668f93c1ee
) again but still see the same problem in Firefox.
oh this is a strange issue, while it only appears when there are at least "visually" two lines of text in the textbox. I thought that I had it fixed.
hi @pkaminski , I'm unable to stop the event handlers without introducing other issues so I have taken your suggestion, to add a class to the textarea. The css class pastable-focus
was added long ago, just wasn't taking into account of the "fake" focuses. Now I've made it available to determine whether focus
&blur
events are "fake" ( 091813e ). You need to check whether it was focus before the fake focus
and after the fake blur
to see whether they are "fake" events. Still there is an example in the index.html
. Open the console in Firefox, then you can see the result.
This works nicely for me, thanks! Please let me know when you've cut a release with this code.
Hey @layerssss, could you please cut a new Bower release with this fix? Thanks.
hi @pkaminski sorry for the delay, I just pushed a new release with all those fixes, it's 0.0.16
In v0.15, the
pasteText
event is delayed, which makes it impossible for my code to tell apart a blur on thetextarea
that's due to pasting (and activating thecontentEditable
container) vs due to the user actually focusing another element. This is important in my use case because blurring an emptytextarea
actually deletes it, so regaining focus later comes too late. I could delay my blur handler as well but this creates a race condition.If the
pasteText
event needs to be delayed, could you fire an undelayed event first or otherwise indicate that the blur is temporary and focus will be regained shortly? Thanks.