On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard gl...@zewt.org wrote:
Hallvord: By the way, please add the editor of the HTML spec to the
beginning of the list in your references. It's strange to list a bunch of
author names, but not the person who actually writes the spec.
Is anything
In addition, from a security perspective, what stops a malicious website
from embedding something like img src=file:///etc/passwd
style=display:none/img in the markup?
We disallow this on copy by stripping such references.
Hi Ben,
picking up this old thread..
So we need to add a sanitize
So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is
there anyone on the IE team present on the list who is able to comment on
this?
-Hallvord R
On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
In addition, from a security
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote:
I think I'd suggest avoiding the mess of execCommand altogether, and add new
methods, eg. window.copy() and window.cut() (or maybe just one method, with
a cut option). execCommand is such a nonsensical way to expose an API
I'm all in favor of a new API as well.
Sincerely,
James Greene
On Fri, May 23, 2014 at 5:53 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote:
I think I'd suggest avoiding the mess of execCommand altogether, and add
new
On 23/05/2014 14:33 , James Greene wrote:
I'm all in favor of a new API as well.
Me too, as discussed in
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0550.html.
I wouldn't put this on window though; why not put it on Selection?
--
Robin Berjon - http://berjon.com/ -
I wouldn't put this on window though; why not put it on Selection?
This kind of copy does not implicitly have anything to do with Selection,
unless we continue to have its default action be copying the currently
selected text. It is substantially more likely to be used for custom text
Moreover, the clipboard is systemwide, when selection exists per document.
So in my opinion window is a better choice.
On Fri, May 23, 2014 at 3:21 PM, James Greene james.m.gre...@gmail.comwrote:
I wouldn't put this on window though; why not put it on Selection?
This kind of copy does not
Hallvord: By the way, please add the editor of the HTML spec to the
beginning of the list in your references. It's strange to list a bunch of
author names, but not the person who actually writes the spec.
On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote:
This kind
Maybe it's just me but... I would personally never want the browser to
automatically assume what I wanted copied and into which clipboard
segments, with the possible exception of a Selection.
I would prefer something very explicit, e.g.:
```js
window.clipboard.copy({
text/plain: BLAH,
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
button.onclick = function(){
button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
data:'Hello world'});
// did that succeed or not? We don't have event.clipboardData on a clip
event
On Tue, May 20, 2014 at 12:01 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
On the other hand, perhaps we could just observe the clipboardData.items
list? If this list is not empty, the payload must have been changed during
processing. So if the default is prevented OR
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
button.onclick = function(){
button.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain',
data:'Hello world'});
// did that succeed or not? We don't have event.clipboardData on a clip
event
Maybe. It seems some refactoring is needed either way. The underlying
data model for .items is drag data store item list which is a term
that's somewhat different from what we have here.
I think that's a feature, not a bug - for example, many operating systems let
you 'copy' and 'paste' files
On Tue, May 20, 2014 at 12:16 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
The way HTML5 specs setData() and the other parts of the API shouldn't cause
any problems for our use case, no?
I guess.
In any event, you should refer to the underlying concepts, not the API
side of things. If
On Tue, May 20, 2014 at 3:42 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
I'm a little confused. Script-generated events never have a default
action,
I think I'd suggest avoiding the mess of execCommand altogether, and add
new methods, eg. window.copy() and window.cut() (or maybe just one method,
with a cut option). execCommand is such a nonsensical way to expose an
API that trying to stay consistent with its commands is probably not much
of a
Hi,
I'm about to file a bug on implementing click-to-copy and click-to-cut per
latest clipboard events spec in Gecko / Firefox, and this reminds me we haven't
yet answered the question about discoverability. This functionality has a
fallback story (Flash shims for platforms with Flash support
On Mon, May 19, 2014 at 3:09 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
Questions:
1) Is this a good idea?
2) What's the spec supposed to say to invoke hasFeature() and define a
feature string for its argument list?
hasFeature() is pretty much killed (always returns true).
Why can't
Hi,
there's a very annoying gotcha in the clipboard events spec: the default
action of for example the copy event is to copy any selected text in the page
(and do nothing if there is no selection). This remains the default action even
if you use event.clipboardData.setData() and friends
On Mon, May 19, 2014 at 3:50 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
a) The event is script-generated and has a data payload (new
ClipboardEvent('copy', {dataType:'text/plain', data:'Hi World'}))
b) Any event listener calls setData() or modifies the DataTransfer payload
some other
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne
van Kesteren ann...@annevk.nl
Can you sanely explain those using a JavaScript implementation or would that
be some kind of weird stack-inspecting feature?
My impression was that it would be something like:
if (data)
Why can't this feature be discovered? The clipboard cannot be made
readable when you just copied to it using this technique?
How would that be discoverable? The feature would have to be supported and
triggered by a user before the status would be known. If the feature
wasn't supported, we
hasFeature() is pretty much killed (always returns true).
That sort of sucks .. I know the argument against it but the question I'm
looking at now shows that not all features are suitable for feature detection -
in this particular case because the whole point of the feature is about user
Can you sanely explain those using a JavaScript implementation or would that
be some kind of weird stack-inspecting feature?
My impression was that it would be something like:
if (data) {
this.preventDefault();
}
Domenic: thanks for explaining, that's pretty much exactly what I'm
for a couple isolated web-compatibility hacks where
dispatching an event in script has side-effects, like click. As far as I
can tell, clipboard events (tested copy and paste) aren't in that category
in Firefox, at least (Chrome doesn't have ClipboardEvent). Can you clarify?
(Unless we're talking
On Mon, May 19, 2014 at 9:21 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
(...)
Any better idea?
-Hallvord
Well, since you need might a new API (because the fallback is just so
nasty and detection is not trivial), dump it somewhere like in the
navigator object:
Also on Mac, there is no !--StartFragment-- and !--EndFragment-- and the
serialized markup copied into the clipboard (called pasteboard on Mac) needs
to contain the precisely the markup that got copied by the user.
Good point. Perhaps we should make sure any OS specific items like
On Apr 7, 2014, at 3:37 PM, Ben Peters ben.pet...@microsoft.com wrote:
After working with developers inside and outside Microsoft, it seems
there are several types of paste that make sense in various scenarios.
For instance,
1- if pasting into a rich document, it could be important to
After working with developers inside and outside Microsoft, it seems there
are several types of paste that make sense in various scenarios. For
instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting into a wiki from an
How hard do you think this is to implement?
Thanks for the code sample and thoughts! I'll run it by a few more
developers to get deeper insight and get back to you.
Great! Note that the code samples are just to get us started thinking about the
issues we'll have to tackle if we're going to
One possibility would be to do something similar to Firefox, but also
include a text/css clipboard item, which contains styles relevant to
what is copied
This seems like an excellent idea! I'm not sure how hard it is to implement,
but it might be doable without too much effort. Some
After working with developers inside and outside Microsoft, it seems there are
several types of paste that make sense in various scenarios. For instance,
1- if pasting into a rich document, it could be important to maintain source
styling information.
2- When pasting into a wiki from an
After working with developers inside and outside Microsoft, it seems there are
several types of paste that make sense in various scenarios. For instance,
1- if pasting into a rich document, it could be important to maintain source
styling information.
2- When pasting into a wiki from an
Hi Daniel,
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample
(http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it looks
like if a user pastes in some HTML that references local images, IE11
automatically captures the
On Wed, Feb 12, 2014 at 1:25 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially
since the IE team has done some interesting work in this area and is
arguably ahead of the rest! :-)
The IE11 API you
Second, can you provide the javascript for how a site would put them into
the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR
uploads from the paste processing, and shows some intermediate 'loading'
animation or something before it gets the
Of course it would be nice to support a script that wants to generate random
HTML with embedded files to place on the clipboard (although I think most of
those use cases can already be met by using URLs and assuming that any
software reading HTML from the clipboard can understand URLs..).
Of course it would be nice to support a script that wants to generate random
HTML with embedded files
X
use case for example with a CANVAS app where the script wants to copy the
state of the CANVAS
I was thinking about images that aren't available cross-domain
Indeed, that's another use
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially since the
IE team has done some interesting work in this area and is arguably ahead of
the rest! :-)
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and
it was designed as a
simple
]
Sent: Thursday, January 23, 2014 5:30 PM
To: public-webapps
Subject: [clipboard events] seeking implementor feedback on using CID: URI
scheme for pasting embedded binary data
Hi,
pasting HTML that contains embeds (images, video) into a rich text editor is
a use case we should cover. It's
on file:/// URLs with local paths and all
[2], this is of course a bug.
* Right now I'm not sure what WebKit/Blink - based implementations do. Test
results welcome!
As the editor of the Clipboard Events spec, I'm proposing a somewhat different
take on this: cid:-URIs for embeds. See
http
from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent
this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)
would
I'm eager to replace our flash clipboard bridge with this native api.
Uh, I'm glad you like it but I wouldn't hold my breath.. I hope implementors
will like it too but I have no way to tell when implementations will actually
be available.
Would this be the correct code to write a string to
On Fri, 10 Feb 2012 01:24:05 +0100, Ian Hickson i...@hixie.ch wrote:
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?
This is a good question.
Presumably the scenario is that hostile page A provides some
On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote:
Now, I don't think that was the question Daniel Cheng was asking. If you
look at the HTML/XHTML specific instructions for the paste event (in the
processing model section:
http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see
This discussion seems to raise the issue of what happens to URLs to images (or
other embedded objects) that are unresolved but become resolved when pasted.
E.g. file:///Users/anton/Library/AddressBook
(if that ever made sense)
Should these also be sanitized away so that they do not, suddenly
On Wed, 18 May 2011, Daniel Cheng wrote:
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote:
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
http://dev.w3.org/2006/webapi/clipops/clipops.html
Feedback especially welcome on the processing model:
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model
and the new list of data types an implementation must be aware of:
On Thu, 19 May 2011 09:43:33 +0900, João Eiras joao.ei...@gmail.com
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
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
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote:
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
On Wed, May 18, 2011 at 8:41 PM, João Eiras joao.ei...@gmail.com wrote:
More generic
- text/* (I've see in too many places mime-types like text/x-c-src, and
text is text.)
- application/*+xml
+1
- application/*script (ecmascript, javascript)
Well, unlike the two above, there's no
On Wed, May 18, 2011 at 5:41 PM, João Eiras joao.ei...@gmail.com wrote:
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)
How do we know that these types don't contain
On Wed, May 18, 2011 at 17:41, João Eiras joao.ei...@gmail.com wrote:
On , Paul Libbrecht p...@hoplahup.net 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
On Thu, May 19, 2011 at 04:01, João Eiras joao.ei...@gmail.com wrote:
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote:
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 Tue, 10 May 2011 05:34:17 +0900, Ian Hickson i...@hixie.ch wrote:
(Sorry for the long delay in responding to this.)
No problem, I know what you've been up to :-p
I'm re-ordering this reply a bit to get to the main questions first.
There's no processing model. IMHO we need a list of
On Tue, 17 May 2011 16:12:50 +0900, Paul Libbrecht p...@hoplahup.net
wrote:
I would like to add all of the 3 MathML flavors:
- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml
Would any special processing be required for any of them?
If not, if
On Tue, May 17, 2011 at 22:07, Hallvord R. M. Steen hallv...@opera.comwrote:
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will be
so rare that throwing is fine? After all, most applications manipulate the
On Wed, 18 May 2011 15:49:33 +0900, Daniel Cheng dch...@chromium.org
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
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen hallv...@opera.comwrote:
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
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
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
On Mon, May 9, 2011 at 4:34 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 08 Jan 2011 05:02:02 +0900, Ian Hickson i...@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
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
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
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
On , Paul Libbrecht p...@hoplahup.net 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
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
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
On Wed, May 18, 2011 at 5:43 PM, João Eiras joao.ei...@gmail.com wrote:
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ?
It fires copy/paste events.
- Ryosuke
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote:
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
On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org
wrote:
A website maker for, say, a shop for furnitures that knows they can go
into my home plan maker through the clipboard will want to be
On Mon, May 16, 2011 at 21:23, Hallvord R. M. Steen hallv...@opera.comwrote:
On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng dch...@chromium.org
wrote:
I'd go one step further and say that there should be some agreement on
what
MIME types ought to be supported to try to insure somewhat
On Mon, May 16, 2011 at 22:57, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen
hallv...@opera.comwrote:
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org
wrote:
A website maker for, say, a shop for furnitures that knows they
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
On 01/31/2011 11:02 AM, Ryosuke Niwa wrote:
On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen
hallv...@opera.com mailto:hallv...@opera.com wrote:
On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa rn...@webkit.org
mailto:rn...@webkit.org wrote:
In an editable context, the
On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
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
On Tue, May 17, 2011 at 1:16 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
I think Webkit's and Gecko's behavior makes more sense.
You paste to some location in the editable area, not to root of it.
But selection could be a range. Why would you arbitrarily pick one end
point?
- Ryosuke
On Tue, May 17, 2011 at 00:12, Paul Libbrecht p...@hoplahup.net 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
Le 17 mai 2011 à 19:06, Daniel Cheng a écrit :
I would like to add all of the 3 MathML flavors:
- application/mathml-presentation+xml
- application/mathml-content+xml
- application/mathml+xml
paul
I don't think we need all 3. Why not just application/mathml+xml?
Daniel,
you do mean
On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org
wrote:
I believe this problem is solvable without a spec change.
OK. I'd like to put in some non-normative warning or note about this
problem though.
On Windows and Mac, implementations can use a native clipboard
On Tue, May 17, 2011 at 14:03, Hallvord R. M. Steen hallv...@opera.comwrote:
On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org
wrote:
I believe this problem is solvable without a spec change.
OK. I'd like to put in some non-normative warning or note about this
problem
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen hallv...@opera.comwrote:
text/plain
text/html
image/jpg
image/gif
image/png
application/xhtml+xml
image/svg+xml
What about image/webp? +1 for being able to copy/paste binary data either
through application/octet-stream or perhaps
On Tue, May 17, 2011 at 16:26, Ryan Seddon seddon.r...@gmail.com wrote:
What about image/webp?
I'd suggest that if we want to support image formats in the spec, we should
try to support the same set that Canvas::toDataURL() does.
+1 for being able to copy/paste binary data either through
On Wed, 18 May 2011 09:13:19 +0900, Daniel Cheng dch...@chromium.org
wrote:
I'd suggest that if we want to support image formats in the spec, we
should
try to support the same set that Canvas::toDataURL() does.
I'll have a look at image formats, thanks for pointing me to toDataURL() :)
On Tue, May 17, 2011 at 20:44, Hallvord R. M. Steen hallv...@opera.comwrote:
Do native OS clipboards generally tend to have a data type saying this is
some random binary data? That's more or less what I think
application/octet-stream indicates on the web. If there isn't a common
format to map
On Wed, 18 May 2011 08:14:42 +0900, Daniel Cheng dch...@chromium.org
wrote:
Interesting. What, in your view, should the implementation do if it
discovers the contents has changed while a paste event thread is
running?
Safari returns an empty string from getData() if this happens. If the
IMO getData() should be 'live' - i.e. return what's on the clipboard.
I think having it return live data could result in potential security
issues. Couldn't a script loop inside the paste event to keep sniffing
out live data?
What should we do about this? Should the spec mandate a
On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng dch...@chromium.org
wrote:
I'd go one step further and say that there should be some agreement on
what
MIME types ought to be supported to try to insure somewhat consistent
behavior across different platforms.
To get a table started in the
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org
wrote:
there should be some agreement on what MIME types ought to be supported
Some types will be predefined but the door should stay opened for others.
I think what you are asking implies that the UA should get out
Le 10 mai 2011 à 00:18, João Eiras a écrit :
I would just model the 'copy' (and 'cut') events exactly as a 'dragstart'
event, ideally so much so that you can literally use the same function for
both. (Canceling 'cut' would prevent the default deletion of the
selection, canceling 'copy' has
On Mon, May 9, 2011 at 23:31, Paul Libbrecht p...@hoplahup.net wrote:
Le 10 mai 2011 à 00:18, João Eiras a écrit :
I would just model the 'copy' (and 'cut') events exactly as a
'dragstart'
event, ideally so much so that you can literally use the same function
for
both. (Canceling 'cut'
Le 10 mai 2011 à 09:13, Daniel Cheng a écrit :
I would expect scripts to want one of two things when they're preventing the
default action:
1. They want to set their own data in the clipboard instead of what the
browser would normally provide by default--for example, a document editor
I'm not really excited by the return of the attack on context menus.
Allowing web sites to hold user's browsers hostage is a bad starting
point. It might be ok if the user had to first opt into rich editing -
maybe.
Note that we only recently added protection for users against 'what
you see is
The alternative is sites that attempt to implement this functionality by
preventing the default and clearing all the data on the clipboard instead.
I'm not really sure that's any better.
Daniel
On Tue, May 10, 2011 at 00:41, timeless timel...@gmail.com wrote:
I'm not really excited by the
Can you expand on what kind of protection this was?
Isn't it simply the same as a copy static content, copy text, or really
copy kind of command?
paul
Le 10 mai 2011 à 09:41, timeless a écrit :
Note that we only recently added protection for users against 'what
you see is not what you copy'
On Tue, May 10, 2011 at 8:41 AM, timeless timel...@gmail.com wrote:
I'm not really excited by the return of the attack on context menus.
Allowing web sites to hold user's browsers hostage is a bad starting
point. It might be ok if the user had to first opt into rich editing -
maybe.
Note
(Sorry for the long delay in responding to this.)
On Wed, 26 Jan 2011, Hallvord R. M. Steen wrote:
On Fri, 24 Dec 2010 07:21:35 +0900, Paul Libbrecht p...@hoplahup.net wrote:
- this seems to support the insertion in the clipboard's data of other
types than what is currently commonly
I think you'd want to push the script-added data regardless of whether the
event is canceled or not. Why would the script add the data otherwise?
I would just model the 'copy' (and 'cut') events exactly as a 'dragstart'
event, ideally so much so that you can literally use the same function for
On Mon, Jan 31, 2011 at 01:31, Hallvord R. M. Steen hallv...@opera.com
wrote:
On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa rn...@webkit.org wrote:
Another thing. Should getData guarantee to return the same result each time
called within the same event handler? i.e. if some external
Hello,
sorry to be slow.
Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit :
Platform capabilities vary.
- Windows will be unhappy if you use up all the custom clipboard formats
(~65535 or so). There is no way to release formats once registered.
- Mac uses UTIs which are strings but not MIME
1 - 100 of 127 matches
Mail list logo
