Re: [Clipboard] Web API for clipboard changes.

[Kelvin Poon]

My pleasure.
Here is the link to a more detailed design doc.  Please feel free to
comment.
https://docs.google.com/document/d/1z1-IW4-Y0NQEAQqzdPdbn5yz0jX4pvfugHU0_L4iIog


On Tue, Jun 16, 2015 at 4:11 AM Arthur Barstow 
wrote:

> On 6/16/15 6:58 AM, James M. Greene wrote:
> >
> > Please share it with the rest of the group. Thanks!
> >
>
> Agree. Kelvin - please do.
>
> -Thanks, AB
>
>
>

Re: [Clipboard] Web API for clipboard changes.

[Arthur Barstow]

On 6/16/15 6:58 AM, James M. Greene wrote:


Please share it with the rest of the group. Thanks!



Agree. Kelvin - please do.

-Thanks, AB

Re: [Clipboard] Web API for clipboard changes.

[James M. Greene]

Please share it with the rest of the group. Thanks!

Sincerely,
   James M. Greene
On Jun 15, 2015 5:48 PM, "Kelvin Poon"  wrote:

> Thank you for your interest Arthur.
> I have drafted up a more detailed implementation doc and shared it with
> you and Hallvord.
>
> Please feel free to take a look and comment.
>
> Kelvin
>
> On Thu, Jun 11, 2015 at 3:57 AM Arthur Barstow 
> wrote:
>
>> On 6/2/15 4:05 PM, Kelvin Poon wrote:
>> >
>> > Hi public-webapps
>> >
>> >
>> > We are exploring a new web API for content to be notified of clipboard
>> > changes and would like to discuss it here.
>> >
>> >
>> > The problem
>> >
>> > For certain classes of web apps, it is necessary to determine when new
>> > clipboard contents have been set, e.g. in order to fetch and display
>> > them, to update context menus, or synchronize the content with another
>> > application or device.
>> >
>> >
>> > The problem is that the web standard currently provides no explicit
>> > notifications when new content is copied from another application to
>> > the clipboard.  As a result, these web apps typically re-fetch the
>> > clipboard every time they regain focus, and only act on the contents
>> > if they have changed since last time (e.g. passing it to a remote
>> > system, updating context menu, etc).  This polling mechanism is
>> > generally inefficient, especially when the clipboard contains a large
>> > image file.
>> >
>> >
>> > We currently have interest from Citrix and Chrome Remote Experience
>> > teams in improving Chrome's clipboard support.
>> >
>> >
>> > The proposal
>> >
>> > Google propose to update the W3C Clipboard API and events
>> > specification with an
>> > onClipboardChangedevent on the document object.  The user agent should
>> > only signal the event if
>> >
>> > 1. a frame re-gains focus AND
>> >
>> > 2. the clipboard has changed since it last had focus.
>> >
>> >
>> > In addition, the user agent should not signal clipboard change events
>> > while a frame has focus.  This will relieve the web app from the
>> > burden of filtering out notifications in response to clipboard changes
>> > generated by the app itself.
>> >
>> >
>> > We think this new API will avoid fetching large clipboard content
>> > repeatedly and unnecessarily for clipboard changes.
>> >
>> > Does the community think this API would be useful?
>> >
>>
>> Hallvord, All - do you have any feedback for Kevlin?
>>
>> > We can go into more details and work on a detailed design together if
>> > the community is interested.
>> >
>>
>> Kelvin, if there is a resource that includes details, please let us
>> know. (I suppose another option is a Pull Request but it might make
>> sense to first wait for some feedback from the group.)
>>
>> -Thanks, ArtB
>>
>>
>>
>>

Re: [Clipboard] Web API for clipboard changes.

[Kelvin Poon]

Thank you for your interest Arthur.
I have drafted up a more detailed implementation doc and shared it with you
and Hallvord.

Please feel free to take a look and comment.

Kelvin

On Thu, Jun 11, 2015 at 3:57 AM Arthur Barstow 
wrote:

> On 6/2/15 4:05 PM, Kelvin Poon wrote:
> >
> > Hi public-webapps
> >
> >
> > We are exploring a new web API for content to be notified of clipboard
> > changes and would like to discuss it here.
> >
> >
> > The problem
> >
> > For certain classes of web apps, it is necessary to determine when new
> > clipboard contents have been set, e.g. in order to fetch and display
> > them, to update context menus, or synchronize the content with another
> > application or device.
> >
> >
> > The problem is that the web standard currently provides no explicit
> > notifications when new content is copied from another application to
> > the clipboard.  As a result, these web apps typically re-fetch the
> > clipboard every time they regain focus, and only act on the contents
> > if they have changed since last time (e.g. passing it to a remote
> > system, updating context menu, etc).  This polling mechanism is
> > generally inefficient, especially when the clipboard contains a large
> > image file.
> >
> >
> > We currently have interest from Citrix and Chrome Remote Experience
> > teams in improving Chrome's clipboard support.
> >
> >
> > The proposal
> >
> > Google propose to update the W3C Clipboard API and events
> > specification with an
> > onClipboardChangedevent on the document object.  The user agent should
> > only signal the event if
> >
> > 1. a frame re-gains focus AND
> >
> > 2. the clipboard has changed since it last had focus.
> >
> >
> > In addition, the user agent should not signal clipboard change events
> > while a frame has focus.  This will relieve the web app from the
> > burden of filtering out notifications in response to clipboard changes
> > generated by the app itself.
> >
> >
> > We think this new API will avoid fetching large clipboard content
> > repeatedly and unnecessarily for clipboard changes.
> >
> > Does the community think this API would be useful?
> >
>
> Hallvord, All - do you have any feedback for Kevlin?
>
> > We can go into more details and work on a detailed design together if
> > the community is interested.
> >
>
> Kelvin, if there is a resource that includes details, please let us
> know. (I suppose another option is a Pull Request but it might make
> sense to first wait for some feedback from the group.)
>
> -Thanks, ArtB
>
>
>
>

Re: [Clipboard] Web API for clipboard changes.

[Arthur Barstow]

On 6/2/15 4:05 PM, Kelvin Poon wrote:


Hi public-webapps


We are exploring a new web API for content to be notified of clipboard 
changes and would like to discuss it here.



The problem

For certain classes of web apps, it is necessary to determine when new 
clipboard contents have been set, e.g. in order to fetch and display 
them, to update context menus, or synchronize the content with another 
application or device.



The problem is that the web standard currently provides no explicit 
notifications when new content is copied from another application to 
the clipboard.  As a result, these web apps typically re-fetch the 
clipboard every time they regain focus, and only act on the contents 
if they have changed since last time (e.g. passing it to a remote 
system, updating context menu, etc).  This polling mechanism is 
generally inefficient, especially when the clipboard contains a large 
image file.



We currently have interest from Citrix and Chrome Remote Experience 
teams in improving Chrome's clipboard support.



The proposal

Google propose to update the W3C Clipboard API and events 
specification with an 
onClipboardChangedevent on the document object.  The user agent should 
only signal the event if


1. a frame re-gains focus AND

2. the clipboard has changed since it last had focus.


In addition, the user agent should not signal clipboard change events 
while a frame has focus.  This will relieve the web app from the 
burden of filtering out notifications in response to clipboard changes 
generated by the app itself.



We think this new API will avoid fetching large clipboard content 
repeatedly and unnecessarily for clipboard changes.


Does the community think this API would be useful?



Hallvord, All - do you have any feedback for Kevlin?

We can go into more details and work on a detailed design together if 
the community is interested.




Kelvin, if there is a resource that includes details, please let us 
know. (I suppose another option is a Pull Request but it might make 
sense to first wait for some feedback from the group.)


-Thanks, ArtB