- From: Johannes Wilm <notifications@github.com>
- Date: Fri, 14 Aug 2015 03:19:10 -0700
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/64/131059808@github.com>
@Reinmar Thanks for the reminder! Now the copy event only makes sense if the selection isn't collapsed, right? So in theory, if they would simply cancel the normalization/event of copy if the selection is collapsed, those points would be covered, right? Can you recall whether normalization of non-collapsed selection also gives problems? In general I would agree that they they should make some kind of browser internal copy of the selection and then do everything on that, but I don't know the browser internals either. >> Paste should not work at all through custom UI buttons, If I understand you right. > Why shouldn't paste work? It works right now in contentEditable=true if execCommand() was executed in a trusted event. I am not sure what considerations went into that, but this is how I interpret this passage: > Scripts can not trigger paste actions, not even from user-initiated threads (though the spec leaves the door open to implementing specific permission UIs that will allow this on a per-site basis). http://www.whatcouldbewrong.com/articles/html5-clipboard-support/ --- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/64#issuecomment-131059808
Received on Friday, 14 August 2015 10:19:37 UTC