Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
Le 19 mai 2011 à 02:11, João Eiras a écrit : > getData and setData must work outside clipboard events, like when clicking > paste/copy/cut buttons on a toolbar. The clipboardData object needs to be > exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for "trusted sites" is ok to me but should not be an essential focus of this spec I find. > To handle the getData case, I've thought of adding a proxy clipboard per > browsing context. Read operations read from the proxy clipboard, write > operations write to the proxy and system clipboards. User initiated actions > like dropping, or pasting would update the proxy clipboard with the system > clipboard contents, prior to the event being dispatched on the webpage. I *think* that is a good strategy. paul
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen wrote: > Not 100% sure what you mean by "concerns" - do you mean for example if I > drag a selection that embeds local images from my local word processing > application to an online editor? I don't know how/if DnD handles this use > case. CCing Ian. > > > -- > Hallvord R. M. Steen, Core Tester, Opera Software > http://www.opera.com http://my.opera.com/hallvors/ > We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 5:43 PM, João Eiras wrote: > But there is no way to access the clipboard contents. Or does execCommand > dispatch a synchronous event ? > It fires copy/paste events. - Ryosuke
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ? What if the event is prevented ? Does
execCommand return false ?
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On , Paul Libbrecht wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to "roundtrip" to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml - application/*script (ecmascript, javascript)
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 09:11:56 +0900, João Eiras
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: copy events and content from server
On Wed, May 18, 2011 at 8:10 PM, Hallvord R. M. Steen wrote: > Practically, the other downside is that since we re-use HTML5's DataTransfer > for clipboardData, this will have to be defined in the HTML spec - since > it's a new feature I guess that at this point means it will go into HTML6, > so we won't see it for a while. I think Ian Hickson keeps track of such > feature requests but I'm not entirely sure how to get it onto his list. New features can still be added freely to the WHATWG's draft of HTML, which will presumably be the basis of HTML6 when it arrives, and which implementers can refer to in the meantime. You can post to wha...@lists.whatwg.org or file a bug against HTML5 to get on Ian's list. I assume that the W3C will want to start publishing HTML6 sooner rather than later, too, because otherwise implementers will be forced to refer to the WHATWG copy exclusively if they intend to implement any new features beyond HTML5 (which they will).
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen wrote:
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
getData and setData must work outside clipboard events, like when clicking
paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
exposed on the window, like in IE.
To handle the getData case, I've thought of adding a proxy clipboard per
browsing context. Read operations read from the proxy clipboard, write
operations write to the proxy and system clipboards. User initiated actions
like dropping, or pasting would update the proxy clipboard with the system
clipboard contents, prior to the event being dispatched on the webpage.
Re: copy events and content from server
On Tue, 17 May 2011 15:50:30 +0900, Paul Libbrecht wrote: you seem to have not included João Eiras' answer: Seems I overlooked that indeed. I thought something similar but didn't include this, so it's good that João brought it up. Le 5 mai 2011 à 04:34, João Eiras a écrit : A synchronous XHR solves this use case and there are no magic locks. But, couldn't a better solution, not involving locks, be a variation of what you suggest:? event.clipboardData.pushDataFromRequest(flavour, xhr) This is actually quite nice, IMO. It avoids imposing limitations on the HTTP traffic the way my first suggestion did. Either the script (by listening to readystatechange events) or the UA can show some progress indication. We also get all the same-origin security limitations and CORS (in CORS-supporting UAs) for free. The main downside I see, is that if the request takes more than a couple of seconds to complete, the user might meanwhile have copied something that will get overwritten in an unexpected way. Practically, the other downside is that since we re-use HTML5's DataTransfer for clipboardData, this will have to be defined in the HTML spec - since it's a new feature I guess that at this point means it will go into HTML6, so we won't see it for a while. I think Ian Hickson keeps track of such feature requests but I'm not entirely sure how to get it onto his list. I'm surprised to be the only one pushing this considering the huge wealth of desktop-like services. Use cases such as copy-a-pdf-fragment from Google Docs Drawing, generate a complex ICS, or produce a good raster image from a graph-display... It often seems a bit random what ideas pop up during a standardisation process.. :-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: clipboard events
On Mon, May 9, 2011 at 4:34 PM, Ian Hickson wrote: >> On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson wrote: >> >> > > > Is it intended to also cover cut, copy and paste? >> > > >> > > Sorry, I don't understand the question. >> > >> > Well, for example, the 'cut' operation involves removing or mutating DOM >> > nodes (for contentEditable) or editing the control value (for ) or >> > raw value (for ), and modifying the selection accordingly. >> >> The timing is in scope, how to do the actual modifications is not (i.e. >> I'm not trying to decide how the implementation should figure out what >> DOM nodes to remove when the user selects something and cuts.) > > We probably should define that. Why isn't it just Selection.deleteFromDocument()? http://html5.org/specs/dom-range.html#dom-selection-deletefromdocument
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
Ideally we shouldn't manipulate any data until it's been requested by
the
page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the
HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed
it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read "on
demand".
Shouldn't we have similar concerns about the text/html content of a drop?
Not 100% sure what you mean by "concerns" - do you mean for example if I
drag a selection that embeds local images from my local word processing
application to an online editor? I don't know how/if DnD handles this use
case. CCing Ian.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen wrote:
> What do you think about the current spec text? I've moved the section
> http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
> where we prepare the paste event, because integrating this into the HTML5
> DataTransfer stuff becomes much easier this way. (Previously I spec'ed it so
> that this work would happen on a script calling getData('text/html') but
> that would require some hacking around with the getData() definition in
> HTML5.) This means we read and process the HTML part from the clipboard
> before firing paste, but any binary/embedded data will only be read "on
> demand".
>
>
> --
> Hallvord R. M. Steen, Core Tester, Opera Software
> http://www.opera.com http://my.opera.com/hallvors/
>
Shouldn't we have similar concerns about the text/html content of a drop?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011 15:49:33 +0900, Daniel Cheng
wrote:
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by
the page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-data
to where we prepare the paste event, because integrating this into the
HTML5 DataTransfer stuff becomes much easier this way. (Previously I
spec'ed it so that this work would happen on a script calling
getData('text/html') but that would require some hacking around with the
getData() definition in HTML5.) This means we read and process the HTML
part from the clipboard before firing paste, but any binary/embedded data
will only be read "on demand".
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
