Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)
-   -   Feature test paste event (http://www.velocityreviews.com/forums/t939491-feature-test-paste-event.html)

Tim Down 09-18-2009 12:59 PM

Feature test paste event
 
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 09-18-2009 02:01 PM

Re: Feature test paste event
 
On Sep 18, 1:59 pm, Tim Down wrote:
> 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 09-18-2009 02:14 PM

Re: Feature test paste event
 
On Sep 18, 3:01*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> On Sep 18, 1:59 pm, Tim Down wrote:
>
> > 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?


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 09-18-2009 11:14 PM

Re: Feature test paste event
 
On Sep 19, 12:14*am, Tim Down <timd...@gmail.com> wrote:
> On Sep 18, 3:01*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
> wrote:
>
>
>
>
>
> > On Sep 18, 1:59 pm, Tim Down wrote:

>
> > > 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?

>
> 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/ >

--
Rob

Tim Down 09-19-2009 03:16 PM

Re: Feature test paste event
 
On Sep 19, 12:14*am, RobG <robg...@gmail.com> wrote:
> On Sep 19, 12:14*am, Tim Down <timd...@gmail.com> wrote:
> > 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 09-19-2009 04:00 PM

Re: Feature test paste event
 
On Sep 19, 11:16*am, Tim Down <timd...@gmail.com> wrote:
> On Sep 19, 12:14*am, RobG <robg...@gmail.com> wrote:
>
> > On Sep 19, 12:14*am, Tim Down <timd...@gmail.com> wrote:
> > > 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. ;)

Tim Down 09-28-2009 02:08 PM

Re: Feature test paste event
 
On Sep 19, 5:00*pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Sep 19, 11:16*am, Tim Down <timd...@gmail.com> wrote:
>
> > On Sep 19, 12:14*am, RobG <robg...@gmail.com> wrote:

>
> > > On Sep 19, 12:14*am, Tim Down <timd...@gmail.com> wrote:
> > > > 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


All times are GMT. The time now is 09:09 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.