Feature test paste event

[Tim Down]

I'm developing a WYSIWYG editor using the usual arrangement of an
iframe with designMode turned on and have a problem relating to
detecting and handling user paste actions. I'm using the paste event
in browsers where it exists (which I think is IE 5 and later, Firefox
3 and later and some flavours of WebKit). In other browsers I will
have to resort to detecting key events, thus failing to detect a user
paste from a browser menu or a remapped keyboard shortcut. My problem
is that I can see no way of feature testing for the paste event, and
will be forced into sniffing based on the user agent string. Is there
any way I can avoid this?

Tim

 

[Richard Cornford]

I'm developing a WYSIWYG editor using the usual arrangement
of an iframe with designMode turned on and have a problem
relating to detecting and handling user paste actions. I'm
using the paste event in browsers where it exists (which I
think is IE 5 and later, Firefox 3 and later and some
flavours of WebKit). In other browsers I will have to resort
to detecting key events, thus failing to detect a user paste
from a browser menu or a remapped keyboard shortcut. My problem
is that I can see no way of feature testing for the paste
event, and will be forced into sniffing based on the user
agent string. Is there any way I can avoid this?

Wouldn't sniffing the user agent string require (in addition to the
problems of attempting to derive any information form an arbitrary
sequence of characters that is not even required to be the same for
two consecutive requests, let alone unique to any particularly browser/
version) that you have a comprehensive understanding of which browsers
do or do not support paste events?

You are already in a position where you don't have much choice but
download the code for both alternatives to all browsers, so why not
(attempt to) set them both up and have the first activation of any
paste event listener disable/remove the keyboard handler? In the event
that the paste event listener did not fire (the event is unsupported)
there would be no runtime overhead in paste listener code, and the
keyboard listeners would do their job. And if it does fire you can be
certain the event is supported and so that the keyboard listeners were
unnecessary in that system.

There would be an initial sequencing issue because (assuming the first
paste was keyboard triggered) the key events would happen before the
paste events (except maybe keyup), so there would have to be short
delay between recognising the keyboard input and acting on it, to give
any intervening paste event a chance to act.

Richard.

 

[Tim Down]

Wouldn't sniffing the user agent string require (in addition to the
problems of attempting to derive any information form an arbitrary
sequence of characters that is not even required to be the same for
two consecutive requests, let alone unique to any particularly browser/
version) that you have a comprehensive understanding of which browsers
do or do not support paste events?

Yes, but while I don't yet have that full understanding it was
irrelevant to the question, and I would certainly do the necessary
research and testing before implementing any sniffing. Since I haven't
yet implmemented any sniffing, it is sufficient at this stage to know
that simply that there are browsers that do and do not support the
paste event. Perhaps I shouldn't have mentioned any specific browsers.

You are already in a position where you don't have much choice but
download the code for both alternatives to all browsers, so why not
(attempt to) set them both up and have the first activation of any
paste event listener disable/remove the keyboard handler? In the event
that the paste event listener did not fire (the event is unsupported)
there would be no runtime overhead in paste listener code, and the
keyboard listeners would do their job. And if it does fire you can be
certain the event is supported and so that the keyboard listeners were
unnecessary in that system.

There would be an initial sequencing issue because (assuming the first
paste was keyboard triggered) the key events would happen before the
paste events (except maybe keyup), so there would have to be short
delay between recognising the keyboard input and acting on it, to give
any intervening paste event a chance to act.

That's very helpful, thank you very much. Frustratingly, I should have
thought of this for myself: I have applied similar strategies before.

Tim

 

[RobG]

Yes, but while I don't yet have that full understanding it was
irrelevant to the question, and I would certainly do the necessary
research and testing before implementing any sniffing.

Given that the user agent string database at TNL.net[1] has over
30,000 entries, thorough research will require a substantial
budget.


1. <URL: http://www.tnl.net/ua/ >

 

[Tim Down]

Yes, but while I don't yet have that full understanding it was
irrelevant to the question, and I would certainly do the necessary
research and testing before implementing any sniffing.

Given that the user agent string database at TNL.net[1] has over
30,000 entries, thorough research will require a substantial
budget.

1. <URL:http://www.tnl.net/ua/>

Good thing it's not required then.

Tim

 

[David Mark]

Given that the user agent string database at TNL.net[1] has over
30,000 entries, thorough research will require a substantial
budget.

1. <URL:http://www.tnl.net/ua/>

Good thing it's not required then.

And never was.

 

[Tim Down]

Yes, but while I don't yet have that full understanding it was
irrelevant to the question, and I would certainly do the necessary
research and testing before implementing any sniffing.
Given that the user agent string database at TNL.net[1] has over
30,000 entries, thorough research will require a substantial
budget.
1. <URL:http://www.tnl.net/ua/>

Good thing it's not required then.

And never was.  

I was being dim and got a helpful answer for which I am grateful. If
there's one thing guaranteed to get a helpful answer here, it's
threatening to use browser sniffing.

I still have some keyboard event related stuff I'm going to need to
address soon where I'm struggling to see how to avoid some sort of
sniff, but that's for another day.

Tim