Re: clipboard events

(Responding to multiple E-mails. Plead guilty to Ianesque behaviour there.  
Last draft of spec is http://dev.w3.org/2006/webapi/clipops/clipops.html .)

On Fri, 24 Dec 2010 07:21:35 +0900, Paul Libbrecht <paul@hoplahup.net>  
wrote:

> - this seems to support the insertion in the clipboard's data of other  
> types than what is currently commonly supported by browsers and the  
> minimum quoted there; this is good and important. I think, for example,  
> that such data as the iCal format would fit very well and be very useful  
> here.

It intends to, but this has two open issues:
* I assume that many OS clipboard implementations have an enumerated list  
of "known" formats, I'm not sure if all OSes can handle a request to push  
"text/foobar" data to the clipboard. Does anyone know if we can rely on  
such functionality being truly cross-platform?

* There is not yet a clear way to push multi-part or alternate formats to  
the OS clipboard from JS. To use something like iCal, I guess best  
practise would be to push one human-readable text/plain string for target  
software without iCal support, and one alternate entry in iCal format. I  
guess that can be done with

  DataTransferItem add(in DOMString data, in DOMString type);

I.e. spec for copy event would be
* default action: copy any document selection
* if default action is prevented: push data in drag data store (as  
manipulated by setData() or items.add()) to clipboard, probably mapping  
certain known values to native clipboard formats while doing so.

Ian - would that make sense?

However, what about items.add() called during a paste event listener?  
Currently I do not allow paste event listeners to update the clipboard  
with setData(), it seems strange. Should we just disallow this too?

> - there is a sanitization process for HTML whose basis is described.  
> Verrrry useful. I can't unfortunately answer if it prevents against  
> attacks, it seems so. Allow me to request, however, that you include all  
> children of HTML5, i.e. also MathML and SVG.

I've changed some instances of "HTML markup" to just "markup". Don't know  
if there is anything more explicit that needs changing to make you happy  
here :)..

> - the sanitization process seems to forget the embedded images that need  
> to be... "embedded" within the clipboard (as data: attribute-values  
> maybe). This is the biggest risk of transferring any HTML or XML based  
> formats, to my taste, after the script elements, and it includes also  
> the call to any "related material" (DTDs, imported OWL ontologies, ...).

I'm experimentally addressing this issue with DataTransferItems type File  
- I'm however unsure how to do it in a safe way yet allow the <img  
src="file://.."> case, which seems like a common one. See  
http://dev.w3.org/2006/webapi/clipops/clipops.html#binary-paste

This is the biggest unsolved problem, and I guess we may have to leave it  
unsolved and not support this use case.

> Could I also request that Opera considers the chapter 6 of MathML which  
> specifies a pure-markup-based method to indicate alternate clipboard  
> formats?

I don't think this is in scope for my spec - though perhaps it could say  
that other specs may define their own serialization formats for copy/cut  
operations..?

On Fri, 24 Dec 2010 07:25:13 +0900, Dmitry Titov <dimich@chromium.org>  
wrote:

> Seems the clipboardData object may simply implement
> dataTransfer<http://dev.w3.org/html5/spec/dnd.html#the-datatransfer-interface>interface.

The spec now defers to HTML5 and uses the DataTransfer interface.

> This would give it legacy setData/getData as well as
> items <http://dev.w3.org/html5/spec/dnd.html#datatransferitems>

I also mention items now.

>> On Mon, 27 Dec 2010 14:24:39 +0900, Robert O'Callahan  
>> <robert@ocallahan.org> wrote:
>>
>>  The sanitization algorithm needs to consider <style> elements and  
>> 'style' content attributes. Some browsers, e.g. IE, support CSS  
>> features that
>>> allow script execution.

>> Good point. Would it be sufficient to say something like
>> "If the implementation supports embedding javascript: URLs or other  
>> forms
>> of scripting inside CSS instructions, such scripts must be removed." ?

> Probably not. One problem is that if some implementation supports
> CSS-triggered scripts via some CSS extension, then ideally other
> implementations would ensure that those extensions are stripped. E.g.  
> Opera doesn't support IE's expression() CSS extension, but if an Opera  
> user pastes untrusted HTML into a Web site, IE users may become  
> vulnerable.

That is something the server needs to deal with. After all, an Opera user  
might also edit the source directly and insert malicious attacks on IE  
users - not that I'd ever suggest our users are evil, of course ;)

That said, I'm not sure if that sanitisation algorithm should be there at  
all. It's both too draconian (removing form elements the user might want  
to paste) and not sufficient to really guarantee security of either the  
paste data's origin or the data's target. For example, if the origin site  
inserts a comment
<!-- user hallvord successfully logged in, session ID  
mfr04m387fusmfrddh7t1hho90 -->
pasting text from that site into a malicious one could enable session  
hijacking. If we could assume "paste" always means the user trusts the  
website they are pasting into, things would be easier..but we all know we  
can't assume anything beyond the user intending to give that website  
access to the data the user *knows* is on the clipboard.

Perhaps the "default" mode should be supporting only text/plain paste, and  
only web apps/sites with some sort of elevated privileges would be able to  
do getData('text/html')..

On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:

>> In an editable context, the paste event's target property refers to the
>> element that contains the start of the selection. In a non-editable
>> document, the event is targeted at a node focused by clicking or by an
>> interactive cursor. If the node that has focus is not a text node, the  
>> event is targeted at the BODY element.
>>
> I'm not sure if it makes sense for the element to be the start of  
> selection.

It's simply spec'ed that way because both Firefox and WebKit agree on  
doing so ;)

>  Why not just pass the root editable element?

That's what IE does.

> Mentioning of
> clicking or cursor is unnecessary.  One can use keyboard to move focus /
> selection and copy / paste should still work.

Yes, it's meant to be an example - I added the words 'for example'.

> I'm not sure why we're
> special-casing text node / non-text node.  Is there some reason to this?
>  (i.e. compatibility with Internet Explorer?)

Compatibility with what I thought WebKit was doing. However, looking more  
closely at the test - it has <input type="image"> in a non-editable  
document, does input.focus() and checks event.target of a paste event - I  
see that focus() did not in fact focus the input as I expected. I've  
removed the special casing of non-text node. (No other implementation fire  
paste events here - at least no without some beforepaste trickery - so I  
ignore them for now.)

> compatible with
> http://msdn.microsoft.com/en-us/library/ms535220(v=vs.85).aspx but I  
> guess getData and setData's return type prevent this.

I guess at least setData() and clearData() could easily return a boolean  
in HTML5 too. Ian? (I assume it indicates whether the clipboard operation  
succeeded or not).


> Internet Explorer already implements most of
> this spec but ClipboardData is implemented as a property of window  
> object. Why deviate?

To me it seems to express much more clearly that this stuff is only  
available as a consequence of those events being triggered by the user. As  
such, event.clipboardData seems nicer than window.clipboardData. (Besides,  
both WebKit and Gecko already made this decision and it seems a useful way  
to let developers object-detect HTML5's stuff versus legacy IE stuff.)

[on security precaution/rules]
> This sounds quite reasonable things to do but I'm not sure if we should
> spec it.  Vendors can decide what to do by themselves.  For example, I'd
> imagine browsers can implement some interactive UI that lets user decide
> whether or not he/she wants to paste / copy certain content on demand.
>  Allowing access only within the event handler might be too restrictive.

I think we should spec the most common and safest case. Vendors are free  
to do what they like anyway.


On Thu, 06 Jan 2011 16:27:33 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote:

>> If getData() is not called from within a paste event handler, or if the
>> type is not available, the method returns undefined

> What should we do if getData is called within a copy event handler?   We
> have an outstanding bug that requests that getData returns the content
> that's about to be copied into the clipboard (
> https://bugs.webkit.org/show_bug.cgi?id=22017).  Should we consider such  
> a behavior?

Thanks for the bug reference, an interesting and very relevant issue. I  
don't think it really makes sense to do what the bug reporter requests,  
because the copy event fires *before* the copy operation takes place. At  
the time, whatever data was on the clipboard previously will still be  
there, returning that in getData() doesn't seem to have much of a use  
case. Returning the new data you're about to copy seems a bit confusing  
since it's not actually the data that is on the clipboard. It also seems a  
bit redundant, given that the event listener has access to the selection,  
can read data from there and do whatever fixes are required, then use  
setData(). So I'd personally prefer the currently spec'ed text, but if  
others want to chime in and "vote for" the "show what we'll place on the  
clipboard" option I'd like to hear any arguments..

>> setData() with unsupported type throws in IE
>>
> We should probably support text / URL as well.

This is now handled - by deferring to HTML5 :)

>> Calling setData() from a paste event handler will modify the data  
>> before it is inserted. Not what WebKit does (but its support for  
>> setData() is
>> non-existant anyway). IE does this.

> And does not modify the clipboard?

This is another somewhat iffy point. I don't think users expect their  
clipboard contents modified if they paste something, so I've changed the  
spec to clearly disallow that - even if we'll be incompatible with IE.

On Fri, 07 Jan 2011 04:31:01 +0900, Ian Hickson <ian@hixie.ch> wrote:

> Is it intended to also cover cut, copy and paste? The current spec draft
> seems very vague about when the events fire and what their default  
> actions are, but I can't tell if that's intentional or not.

Better now?

* Not sure what was unclear about the events' default actions. I've not  
really made any changes except for general editing and rewriting.

* Regarding timing, I've added  
http://dev.w3.org/2006/webapi/clipops/clipops.html#otherevents about how  
those events interact with key events and others.


On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson <ian@hixie.ch> 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 <input>) or
> raw value (for <textarea>), 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.)

> Similarly, 'paste', e.g. for <input>, involves changing the <input>  
> value,
> firing 'input' events, modifying the selection, etc.

> Sure. For example, when should the paste event fire relative to when
> keydown/keyup events fire? When should the paste event fire relative to
> when the 'input' event fires?

Fixed.

> Should it fire asynchronously as a separate
> task; should it fire as part of the default action of the keypress event
> synchronously?

Fixed, I hope it's clear enough.

> Where do these events fire relative to mutation events, for  
> contentEditable? What should the default action of 'paste' be, in terms  
> of DOM mutations when the cursor is in a contentEditable section?

It is fixed to the extent that I consider these things in scope.. I'm  
trying to keep this spec short and sweet :)

> How should
> DataTransfer be set up when the data comes from a non-Web source?

http://dev.w3.org/2006/webapi/clipops/clipops.html#binary-paste is a  
start. Comments would be very welcome, because I'm not sure I understand  
this enough to make sense!

> Another example, more editorial, is that the spec currently doesn't have  
> a
> conformance section and doesn't define how to determine what the  
> normative
> conformance requirements are.

I've kept some boilerplate text from the older clipops draft, hope that'll  
do.

> Assuming RFC2119 semantics, the spec is
> lacking detail. For example, nothing normatively says whether the events
> bubble or not, it's just left up to the reader to assume that the table
> implies that it does.

I've tried to sharpen the use of "must", "must not" and the like. I'm not  
entirely sure why 'Bubbles: yes' in a table isn't normative or explicit  
enough though. There are also plenty of tests that assume the events  
bubble (CVS doesn't let me check in the test suite yet, I don't know why  
but I'm asking Doug..).

> There's also no normative requirement linking the
> description of what the target is to the actual firing of the event.

Since it seems set by the same logic for all three events, I added a  
separate section about determining the target property (rather than  
repeating it three times).

>> In WebKit, event.clipboardData in copy/cut/paste events and
>> event.dataTransfer in drag/drop events both implement a "Clipboard"
>> interface, so the same attributes are available.
>
> In that case we should probably just use the same interface, and put
> copy/paste and drag/drop in the same spec. If they're in separate specs,
> it's probably simplest if the DataTransfer stuff is with the DND stuff,

OK, that's the way we go. The Copy, cut and paste spec (CCnP) now refers  
to HTML5.

> since that's the main driver for changes to the DataTransfer interface.
> I'm happy to work with you to make sure the DataTransfer spec still works
> for copy/paste.

It should sort of work, but I'm not sure what to do about the somewhat  
different terminology used. For example, the DnD spec talks about the  
"drag data store" a lot. Should we just say that for the purpose of the  
CCnP spec, the "drag data store" IS the OS clipboard, or an  
implementation-specific representation of it? Does the CCnP spec need to  
say explicitly how to expose OS clipboard content as a "drag data store"?

On Sat, 08 Jan 2011 03:36:24 +0900, Ojan Vafai <ojan@chromium.org> wrote:

>> I'm not sure if it makes sense for the element to be the start of
>> selection.  Why not just pass the root editable element?

> Ditto on all points. Also, why does this clause not apply to the cut/copy
> events as well?

Fixed in response to Ian's feedback :)

> What does "start" mean here? Start in document order e.g. as opposed to  
> the anchor/base of the selection?

Well, "find node that contains start of selection (in document order)"  
seems to be exactly what WebKit (or at least Chrome/Win) implements here  
:). Firefox goes for the anchor-of-selection approach, while IE chooses  
the "editable ancestor" way. Personally I think Firefox is better but it's  
a very minor detail since script can read the selection anyway.

(It seems no DOM2 Range implementation allows me to make right-to-left  
selections, so I can't make an automated test for what Firefox does :-/ ??  
Haven't changed the spec here.)

>> This .types spec is slightly different from the HTML5 DnD .types -
> consistent enough to make sense to authors and implementers?
>
> What's the benefit of being different?

Now we'll just defer to HTML5, but I have some suggestions to be discussed  
with Ian.

>> Implementations are encouraged to also support text/html for dealing  
>> with
> HTML-formatted data.
>
> In an ideal world, implementations would support any string type. This  
> would
> allow for creating custom clipboard formats as well as common mime types
> (e.g. image types). Do most operating systems support setting generic  
> string
> types on the clipboard?

I don't know, but that's what the spec currently requires implementations  
to support, so I hope so :-p

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Wednesday, 26 January 2011 05:27:26 UTC