Re: [clipboard] Semi-Trusted Events Alternative

2014-07-27 Thread James Greene
  If this is really the case, it seems that separating Copy from Paste
would be proper.

 The spec sort of distinguishes them (but this should probably be spelled
out in detail): per the current spec text, copy/cut can be triggered from
any trusted or semi-trusted event, while paste is only allowed if the UA is
explicitly configured to allow it. But I should explain this better in the
spec - especially because I keep forgetting about this myself ;)

I very much agree: it seems like much of the discussion slowing down
progress on this spec and subsequent implementations is a concern over
unauthorized programmatic access to read the user's clipboard (i.e.
synthetic `paste`) but that is NOT part of the spec, nor would I want it to
be.

That functionality is also NOT supported in Flash: you can still only read
the clipboard contents while handling a user-initiated `paste` operation
into a Flash UI component.

The main desired functionality that is really driving this spec is the
synthetic/programmatic `copy` operation. Looking at ZeroClipboard's [1][2]
usage statistics provides plenty of evidence that this feature is both
increasingly desired by developers [3][4][5] and frequently used by
consumers [6].

[1]: ZeroClipboard home page: http://zeroclipboard.org/

[2]: ZeroClipboard repo: https://github.com/zeroclipboard/zeroclipboard/

[3]: Public websites using ZeroClipboard number well over 30,000:
https://github.com/zeroclipboard/zeroclipboard/wiki#websites-using-zeroclipboard

[4]: ZeroClipboard currently has 3000+ stars on GitHub.

[5]: ZeroClipboard averages more than 1000 installs per week via NPM, which
is only one of many ways/systems by which developers can get ZeroClipboard:
https://www.npmjs.org/package/zeroclipboard

[6]: GitHub usage statistics (as of March 2014) for the ZeroClipboard
click-to-copy buttons indicate an average of 35,000+ clicks per day.

Sincerely,
   James M. Greene
   http://greene.io/


Re: WebApp installation via the browser

2014-05-31 Thread James Greene
You're probably think of IE's Pinned Sites concept on Windows 8:

http://msdn.microsoft.com/en-us/library/gg491731.aspx

Sincerely,
James Greene
Sent from my [smart?]phone
On May 31, 2014 10:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:

 On Sat, 31 May 2014, at 10:40, Jeffrey Walton wrote:
  I have a question about Use Cases for Installable WebApps located at
  https://w3c-webmob.github.io/installable-webapps/.
 
  Under section Add to Homescreen, the document states:
 
  ... giving developers the choice to tightly integrate their web
  applications into the OS directly from the Web browser is
  still somewhat new...
 
  ... [Installable WebApps] are different in that the
  applications are installed directly from the browser itself
  rather than from an app store...
 
  It sounds like to me the idea is to allow any site on the internet to
  become a app store. My observations are the various app stores provide
  vendor lock-in and ensure a revenue stream. Its architected into the
  platform. Companies like Apple, Microsoft and RIM likely *won't* give
  up lock-in or the revenue stream (at least not without a fight).
 
  Are there any platforms providing the feature? Has the feature gained
  any traction among the platform vendors?

 Isn't Add to homescreen feature something you can find in a more or
 less advanced fashion on Safari iOS, Firefox Android, Firefox OS and
 Chrome Android? I believe IE had something similar some time ago on
 desktop but I don't know what's the current status of that. Chrome Apps
 is also doing some experiments on desktop [1].

 [1] https://plus.google.com/+FrancoisBeaufort/posts/74WCmneFJ8j

 -- Mounir




Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

2014-05-23 Thread James Greene
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
  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
  win.

 I'm inclined to agree, FWIW.  If the command is really strictly
 editor-related, and makes sense only in conjunction with an editor
 based on existing commands, I would add it to execCommand for
 consistency (like defaultParagraphSeparator or fontSizePt).  But
 anything else should stay far away.  (Actually, if contenteditable
 wasn't an unsalvageable trainwreck, I would rather write a new API
 that actually follows JS norms, like window.editor.bold() or similar,
 but it is, so there's no point in doing anything beyond *maybe* trying
 to get it a bit more interoperable.)




Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

2014-05-23 Thread James Greene
 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
insertion.


Sincerely,
James Greene



On Fri, May 23, 2014 at 7:43 AM, Robin Berjon ro...@w3.org wrote:

 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/ - @robinberjon



Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

2014-05-23 Thread James Greene
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,
  text/html: bBlah/b,
  application/rtf: {\\rtf1\\ansi\n{\\b Blah}},
  text/x-markdown: **Blah**
});
```

Also, Hallvord et al: switching to a standalone API would also mean that we
can drop all of the `cut`-specific parts of the spec since `cut` requires
an active Selection, right?


Sincerely,
James Greene



On Fri, May 23, 2014 at 10:13 AM, 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.


 On Fri, May 23, 2014 at 8:21 AM, James Greene james.m.gre...@gmail.comwrote:

 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
 insertion.


 I'd assume something like:

 // Copy text:
 window.copyToClipboard(hello);
 // Copy HTML text:
 span = document.createElement(span);
 span.innerHTML = bhello/b;
 window.copyToClipboard(span);
 // Copy an image from a CanvasImageSource:
 window.copyToClipboard(canvas);
 window.copyToClipboard(img);
 // Copy the selection:
 window.copyToClipboard(window.getSelection());
 // Copy HTML text with plaintext alternative:
 dt = new DataTransferItemList();
 dt.add(hello, text/plain);
 dt.add(span.innerHTML, text/html);
 window.copyToClipboard(dt);

 This avoids the busywork of creating a DataTransfer in common cases, but
 allows using DataTransfer when you want to do something more advanced, like
 provide alternatives or explicitly specify a MIME type.  Note
 that DataTransferItemList isn't actually constructable right now.  Note
 that I used DataTransferItemList in the example and not DataTransfer, since
 DataTransfer is only relevant to drag-and-drop.

 I wonder what the right way to handle images is.  Native Windows
 applications can copy pixel data to the clipboard, then paste it back out.
  DataTransferItem wants things to act like strings, though, so you'd have
 to encode the image to a file format.  If that's PNG, that's an expensive
 conversion.  Maybe DataTransferItem should be able to return an ImageSource.

 (As an aside, why is the paste event's .clipboardData not set to the text
 being pasted?  I wanted to see what pasting images did in current browsers,
 but at least in Chrome there's nothing in there, even if I just paste plain
 text.)

 --
 Glenn Maynard




Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

2014-05-19 Thread James Greene
 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 would never know.


Sincerely,
James Greene



On Mon, May 19, 2014 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote:

 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 this feature be discovered? The clipboard cannot be made
 readable when you just copied to it using this technique?


 --
 http://annevankesteren.nl/




Re: Proposal: External Protocol Handling

2014-03-31 Thread James Greene
Would this be similar to the Web Intents spec proposal that Google was
championing (based on Android Intents)?

Sincerely,
James Greene



On Thu, Mar 27, 2014 at 5:52 PM, Ben Johnson ben.john...@citrix.com wrote:

  Hi all,



 I’ve been working on a draft specification for a creating a dedicated
 cross-browser external protocol launching standard based on the behavior of
 msLaunchUri in Internet Explorer.



 The draft is here:
 http://bengjohnson.github.io/ExternalProtocolSpecification.html



 I’m looking for feedback from the web app group members on:



 · What major concerns to you have with the overall approach?

 o   Do you feel there are insufficient motivating factors for a change to
 be made?

 o   Are there unstated concerns missing from the document?

 · What level of detail are you expecting for a complete proposal?

 · Should it be better aligned with web-based protocol handling?
 If so, how?

 · And of course, any particular issues with the document in its
 current form.



 Thanks,

 Ben



Re: Proposal: External Protocol Handling

2014-03-31 Thread James Greene
OK. Thanks for the clarifications, Konstantin  Ben!

Sincerely,
James Greene



On Mon, Mar 31, 2014 at 12:55 PM, Ben Johnson ben.john...@citrix.comwrote:

 Kosta has pretty much covered it. Web Intents as well as current browser
 implementations are heavily geared towards web-based protocol handling,
 potentially at the expense of external handlers.

 The final question in my initial e-mail  Should it be better aligned with
 web-based protocol handling? If so, how? was intended to allude to that -
 I probably should have been more specific.


 -Original Message-
 From: Konstantin Welke
 Sent: Monday, March 31, 2014 7:01 AM
 To: James Greene; Ben Johnson
 Cc: public-webapps@w3.org; Kenneth Auchenberg; Mathieu Hofman
 Subject: Re: Proposal: External Protocol Handling

 Hi!

 I think the biggest difference is that web intents work between web pages,
 whereas this is used to launch installed programs on the user’s computer.

 Think about this use case: A web page with a list of ssh hosts. When you
 click on a link, the JS on the page calls
 navigator.launchUri(“ssh://hostname”) to try to launch your SSH agent. If
 a handler for the “ssh://“ protocol is installed, it presents the user with
 a dialog window to ask whether they want to launch their SSH client (e.g.
 “PuTTY on Windows, ssh in a terminal on Mac, Unix*).

 If the user accepts, the SSH client is launched and the JS successCallback
 is executed; If the user rejects or no SSH client is registered, the SSH
 client is not launched and the noHandlerCallback is executed.

 Currently, one can do that using a plain link or an iframe - however the
 user experience is pretty bad if e.g. no protocol handler client is
 installed (depending on the browser). Each browser has different gotchas
 and limitations that we currently need to work around.

 We would like to have a stable, well-defined API for this that also allows
 to handle the “user declined / protocol handler is not installed” case
 gracefully. As an example, the web page could show a UI to tell the user
 how to install an SSH client.

 Cheers,
 Kosta

 PS: Sorry for the long signature...
 --
 Konstantin Welke
 Senior Software Developer
 Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
 T: +49 721 3544990 | F: +49 721 354499624 | M: +49 151 23429318
 konstantin.we...@citrix.com http://www.citrixonline.com 
 http://www.citrixonline.com/

 Work better. Live better.
 Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
 Geschäftsführer: Tommy Ahlers | Michael DiFilippo | David Zalewski Sitz
 der Gesellschaft: Karlsruhe | Registergericht: Amtsgericht Mannheim HRB
 713721 Citrix Online UK Ltd http://www.citrixonline.com/imprint-en.tmpl


 On Monday, March 31, 2014 at 3:04 PM, James Greene 
 james.m.gre...@gmail.com wrote:

 Would this be similar to the Web Intents spec proposal that Google was
 championing (based on Android Intents)?

 Sincerely,
 James Greene

 On Thu, Mar 27, 2014 at 5:52 PM, Ben Johnson ben.john...@citrix.com
 wrote:

 Hi all,

 I’ve been working on a draft specification for a creating a dedicated
 cross-browser external protocol launching standard based on the behavior of
 msLaunchUri in Internet Explorer.

 The draft is here:
 http://bengjohnson.github.io/ExternalProtocolSpecification.html
 http://bengjohnson.github.io/ExternalProtocolSpecification.html

 I’m looking for feedback from the web app group members on:

 ·
 What major concerns to you have with the overall approach?
 o
 Do you feel there are insufficient motivating factors for a change to be
 made?
 o
 Are there unstated concerns missing from the document?
 ·
 What level of detail are you expecting for a complete proposal?
 ·
 Should it be better aligned with web-based protocol handling? If so, how?
 ·
 And of course, any particular issues with the document in its current form.

 Thanks,
 Ben










Re: [clipboard-api] Do paste events and company bubble?

2014-03-08 Thread James Greene
They are indeed cancelable and bubble-able, as shown in Example 1 under
the Clipboard event interfaces section.[1]

There are also a number of references to canceling the events under the
Processing model section.[2]

That said, yes, you are absolutely correct that this fact should be
explicitly called out somewhere as well.

[1]
http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interfaces

[2] http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model

Sincerely,
James Greene
Sent from my [smart?]phone
On Mar 8, 2014 1:20 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 The clipboard API draft [1] doesn't seem to say whether paste events, or
 any other events fired by fires a clipboard event bubble.  Or whether
 they're cancelable, for that matter.  Presumably it should say something on
 the matter.

 -Boris

 [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#paste-event




Re: [announce] Intent to publish new WD of Clipboard API and Events March 11

2014-03-04 Thread James Greene
So the biggest new addition (IMHO, at least) is the click-to-copy/cut
capability. However, as several browser vendors have already implemented
the previously published Clipboard API, I feel that we really need some way
to feature detect this new ability so we can gracefully degrade to similar
Flash-based click-to-copy functionality if the browser supports the
Clipboard API but doesn't yet support native click-to-copy.

This detection could have been a fulfilled by something like
`document.implementation.hasFeature(...)` but that method seems to have
fallen out of favor (the MDN article notes that it will always return
`true` since Firefox 19).

Similar methods like `document.queryCommandSupported` and
`document.queryCommandEnabled` are both inappropriate (as this new
capability is achieved via dispatching a `ClipboardEvent` during the
handling of a user-initiated semi-trusted event (e.g. `click`), not via a
query command) and also inconsistently supported in browsers (some throw
errors, some return false positives, etc.).

Does anyone else have any suggestions for adding adequate feature detection
to this scenario? If not, we won't [ever?] be able to gracefully degrade
the click-to-copy functionality.

Also, we aren't given any indication as to whether or not the clipboard
injection succeeds. Would it be reasonable to add an aftercopy/aftercut
event in which we could validate the data that made it into the clipboard
(if ANY) matches our expectations?

Sincerely,
James Greene
Sent from my [smart?]phone
On Mar 4, 2014 8:59 AM, Arthur Barstow art.bars...@nokia.com wrote:

 Hallvord is working toward publishing a new WD of Clipboard API and Events
 on (or around) March 11, based on [ED].

 If you have any comments about this proposal, please reply to this thread
 by March 7 at the latest.

 -Thanks, AB

 [ED] http://dev.w3.org/2006/webapi/clipops/clipops-source.
 html?specStatus=WD;publishDate=2014-03-11;previousPublishDate=2013-04-11





Re: Officially deprecating main-thread synchronous XHR?

2014-02-07 Thread James Greene
There are certain situations where sync XHRs are, in fact, required...
unless we make other accommodations. For example, in the Clipboard API,
developers are allowed to inject into the clipboard as a semi-trusted event
during the event handling phase of certain user-initiated events (e.g.
`click`).[1]  This has not yet been implemented in any browsers yet.

However, if browser vendors choose to treat this scenario as it is treated
for Flash clipboard injection, then the semi-trusted state ends after the
default action for that event would occur.[2]

For Flash clipboard injection, this means that any required on-demand
XHRs must be resolved synchronously. For the DOM Clipboard API, it would be
nice to either still be able to use sync XHRs or else we would need to
specially authorize async XHRs that are started during the semi-trusted
state to have their completion handlers also still resolve/execute in a
semi-trusted state.

cc: Hallvord R. M. Steen

[1] http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event

[2]
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()

Sincerely,
James Greene
Sent from my [smart?]phone
On Feb 7, 2014 2:55 PM, Maciej Stachowiak m...@apple.com wrote:


 On Feb 7, 2014, at 9:18 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com
 wrote:
 
  From: Olli Pettay olli.pet...@helsinki.fi
 
   And at least we'd improve responsiveness of those websites which stop
 using sync XHR because of the warning.
 
  I think this is a great point that makes such an effort worthwhile even
 if it ends up not leading to euthanizing sync XHR.

 Agreed. I think for this to be effective we need to get multiple browser
 vendors being willing to add such a warning. We would also need to add text
 to the various versions of the spec (whatwg and w3c).

 Which browsers are game? (I think mozilla is). Which spec editors are?

 I usually hate deprecation warnings because I think they are ineffective
 and time-wasting. But this case may be worthy of an exception. In addition
 to console warnings in browsers and the alert in the spec, it might be
 useful to have a concerted documentation and outreach effort (e.g. blog
 posts on the topic) as an additional push to get Web developers to stop
 using sync XHR.

 Regards,
 Maciej






Re: Fixing appcache: a proposal to get us started

2013-11-25 Thread James Greene
 Your manifest file should be dynamically generated by your server, based
on what you know about the user's browser.
 Now you have one single manifest file which is easier for updates, +
server-side language comments so documentation is easy.
 The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a bad
choice.

I would contest this point as now you're suggesting that the right thing
to do is to force everyone to maintain custom browser detection libraries
on their servers again in order to guess what the browser's capabilities
are.  As we know from much experience with this technique already, it is
brittle and must be constantly monitored and updated as new browser
versions are released.  Why not attempt to give the browser-side manifest
functionality the ability to feature test for file support instead? Then
the browsers can be the trusted source instead of everyone having to create
new divergent browser file support inference hacks.

Sincerely,
James Greene



On Mon, Nov 25, 2013 at 9:30 AM, pira...@gmail.com pira...@gmail.comwrote:

  To be available offline, the device has to hit a server first, then the
 appcache magic happens.

 Obviously.


  No reason the server couldn't prepare / select what to send to the
 device: iOS won't support WebM anytime soon, there is no reason to
 constantly ask iOS device the same info again  again. That just makes no
 sense, and force devs to produce device/os specific files (manifest) anyway.
 
  And it's not AppCache job to do so. Its job is just make a web document
 available offline + make updates simple  easy.
 
 I'm not talking about remove the servers functionality, I only
 disagree with your statement about using only client-side technologies
 is bad, giving the impression that servers are necesary. Not today,
 they are necesary for bootstraping and access content on a reference
 place, but we should remove the idea of a centralized web as far as
 possible. AppCache here is a good tool for this, but here the server
 is only neccesary to generate the custom manifest file, no more, and
 also probably this manifest could be generated directly on client-side
 (don't know if it could be done with today technologies, but at least
 with ServiceWorkers it will be possible, and using them probably the
 AppCache manifest becames useless in this case of use).



 --
 Si quieres viajar alrededor del mundo y ser invitado a hablar en un
 monton de sitios diferentes, simplemente escribe un sistema operativo
 Unix.
 – Linus Tordvals, creador del sistema operativo Linux




Re: Fixing appcache: a proposal to get us started

2013-11-25 Thread James Greene
 This seems to me that this is some kind of add scripting habilities to
 the AppCache manifest, while we already have Javascript, and allowing
 it to do that will lead us to something fairly similar (in fact, a
 sub-set) of what ServiceWorkers can do. Why duplicate efforts then?
 Manifest files are good for static content, but for other cases there
 are better tools.

Yes and no. Primary differences:

1. I'm not advocating for full scriptability, just basic support detection,
e.g.:
  `if accepts(audio/ogg) ...`

The main problem I'd see there is if the browser also needs to know
what plugins
(or even JS libs, I suppose) are capable of consuming.

2. AFAIK, using ServiceWorkers requires that the resources are
programmatically
fetched *by* the ServiceWorker. This is different than a manifest which
is capable
of figuring the cache out on the fly as resources are loaded.

I'm not opposed to just punted and saying that ServiceWorker is the way to
deal
with this, though.  I have no personal use cases at the moment for this
functionality... just playing devil's advocate for the OP. :)

Sincerely,
James Greene



On Mon, Nov 25, 2013 at 11:05 AM, pira...@gmail.com pira...@gmail.comwrote:

  Why not attempt to give the browser-side manifest functionality
  the ability to feature test for file support instead? Then the browsers
  can be the trusted source instead of everyone having to create new
 divergent
  browser file support inference hacks.
 
 This seems to me that this is some kind of add scripting habilities to
 the AppCache manifest, while we already have Javascript, and allowing
 it to do that will lead us to something fairly similar (in fact, a
 sub-set) of what ServiceWorkers can do. Why duplicate efforts then?
 Manifest files are good for static content, but for other cases there
 are better tools.



 --
 Si quieres viajar alrededor del mundo y ser invitado a hablar en un
 monton de sitios diferentes, simplemente escribe un sistema operativo
 Unix.
 – Linus Tordvals, creador del sistema operativo Linux



[clipboard] Add RTF to the mandatory data types list?

2013-10-17 Thread James Greene
Would it be possible to add RTF (MIME type of application/rtf) [1] to the
mandatory data types [2] list?

While it is a proprietary file format held by Microsoft, it also has public
specs [3][4] and is designed for cross-platform interchange of text and
graphics.

More importantly, I speculate that it is one of the top three types of text
formats that people copy-and-paste: plain text, RTF, and HTML. It is also
supported, or at least readable, by almost every word processing
application ever made: Microsoft Word, WordPerfect, WordPad, OpenOffice,
FreeOffice, LibreOffice, etc. This is not limited to desktop office
application either, however, as RTF is also supported by online solutions
such as Google Docs, Zoho Docs, etc.

With all that in mind, it definitely seems like it should be on the
mandatory data types list.

Are there any legal roadblocks to making a proprietary data format a
mandatory type? Are there any other reasons why people think that RTF
should be excluded from the list?

Please let me know and/or discuss.  Thanks!

[1] http://en.wikipedia.org/wiki/Rich_Text_Format
[2] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
[3] RTF spec v1.8
http://www.microsoft.com/en-us/download/details.aspx?id=7105
[4] RTF spec v1.9.1
http://www.microsoft.com/en-us/download/details.aspx?id=10725


Sincerely,
James Greene


Re: [clipboard] Add RTF to the mandatory data types list?

2013-10-17 Thread James Greene
Oh, and I should also mention that the Flash Player clipboard (which we are
trying to kill) supports plain text, HTML, and RTF, as well as custom
application-defined data types.

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html
On Oct 17, 2013 5:44 AM, James Greene james.m.gre...@gmail.com wrote:

 Would it be possible to add RTF (MIME type of application/rtf) [1] to
 the mandatory data types [2] list?

 While it is a proprietary file format held by Microsoft, it also has
 public specs [3][4] and is designed for cross-platform interchange of text
 and graphics.

 More importantly, I speculate that it is one of the top three types of
 text formats that people copy-and-paste: plain text, RTF, and HTML. It is
 also supported, or at least readable, by almost every word processing
 application ever made: Microsoft Word, WordPerfect, WordPad, OpenOffice,
 FreeOffice, LibreOffice, etc. This is not limited to desktop office
 application either, however, as RTF is also supported by online solutions
 such as Google Docs, Zoho Docs, etc.

 With all that in mind, it definitely seems like it should be on the
 mandatory data types list.

 Are there any legal roadblocks to making a proprietary data format a
 mandatory type? Are there any other reasons why people think that RTF
 should be excluded from the list?

 Please let me know and/or discuss.  Thanks!

 [1] http://en.wikipedia.org/wiki/Rich_Text_Format
 [2] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
 [3] RTF spec v1.8
 http://www.microsoft.com/en-us/download/details.aspx?id=7105
 [4] RTF spec v1.9.1
 http://www.microsoft.com/en-us/download/details.aspx?id=10725


 Sincerely,
 James Greene




Re: Sync API for workers

2013-10-14 Thread James Greene
Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of words it should take.

Not sure on prior art within the web platform.
On Oct 14, 2013 4:59 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
 dtel...@mozilla.com wrote:
  Let me introduce the first sketch of a variant. The general idea is to
  add a |postSyncMessage|
 
  We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
 
  interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
void postMessage(any message, optional sequenceTransferable
 transfer);
any postSyncMessage(any message, optional sequenceTransferable
  transfer);
  };
 
  interface SyncMessageEvent : MessageEvent {
void reply(optional any message, optional sequenceTransferable
  transfer);
  };

 This API was suggested by Olli way up in this thread. It has a few
 downsides:

 1. It only allows a single synchronous message channel. That means
 that if you have several libraries that all need synchronous
 communication with the parent they have to coordinate on some way to
 distinguish each others messages. The fact that Gecko hasn't had
 MessageChannel support has resulted in the same problem for
 asynchronous communication and that has been a big headache for
 developers.
 2. It doesn't support streaming return values. I.e. you can't send
 multiple return values from a single postSyncMessage call.
 3. It doesn't allow direct synchronous communication between a worker
 and the workers grand parent. Everything single message has to be
 individually routed through the parent.
 4. What happens if you have multiple eventlisteners in the parent and
 several of them call .reply()?

 I wouldn't say that all of these are killer issues. I do think the
 first one is though. And the other three are clearly downsides.

 All in all I think the added complexity in the later proposal is worth it.

 / Jonas




Re: Sync API for workers

2013-10-13 Thread James Greene
Thanks for adding clarification. That CAN be true but it depends on the
environment [so far as I can see].

For example, such an API wrapper couldn't be built in today's client-side
JavaScript because the UI thread can't do a synchronous yielding sleep
but rather can only do a synchronous blocking wait, which means it wouldn't
yield to allow for the Worker thread to asynchronously respond and toggle
such a condition/mutex/etc. unless such can be synchronously requested by
the blocking thread from within the busy wait loop (e.g.
`processEvents();`) as browsers won't interrupt the synchronous flow of the
JS busy loop to trigger `onmessage` handlers for async messages sent from
the Worker.

If I'm mistaken, please consider providing a code snippet, gist, etc. to
get me back on track. Thanks!
On Oct 13, 2013 5:06 AM, David Rajchenbach-Teller dtel...@mozilla.com
wrote:

 On 10/12/13 3:48 PM, James Greene wrote:
  You can only build a synchronous API on top of an asynchronous API if
  they are (a) running in separate threads/processes AND (b) the sync
  thread can synchronously poll (busy loop) for the progress/completion of
  the async thread.

 a) is necessary, but for b) it is sufficient for the sync thread to be
 able to sleep until a condition/mutex/... is lifted


 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla



Re: Sync API for workers

2013-10-13 Thread James Greene
 a) is necessary, but for b) it is sufficient for the sync thread to be
 able to sleep until a condition/mutex/... is lifted

In other words, your clarification is completely true but my initial
statement was written with regard to client-side JavaScript, which cannot
sleep. As such, I believe my original assertions are still correct with
regard to writing a sync wrapper in JS.
On Oct 13, 2013 9:09 AM, James Greene james.m.gre...@gmail.com wrote:

 Thanks for adding clarification. That CAN be true but it depends on the
 environment [so far as I can see].

 For example, such an API wrapper couldn't be built in today's client-side
 JavaScript because the UI thread can't do a synchronous yielding sleep
 but rather can only do a synchronous blocking wait, which means it wouldn't
 yield to allow for the Worker thread to asynchronously respond and toggle
 such a condition/mutex/etc. unless such can be synchronously requested by
 the blocking thread from within the busy wait loop (e.g.
 `processEvents();`) as browsers won't interrupt the synchronous flow of the
 JS busy loop to trigger `onmessage` handlers for async messages sent from
 the Worker.

 If I'm mistaken, please consider providing a code snippet, gist, etc. to
 get me back on track. Thanks!
 On Oct 13, 2013 5:06 AM, David Rajchenbach-Teller dtel...@mozilla.com
 wrote:

 On 10/12/13 3:48 PM, James Greene wrote:
  You can only build a synchronous API on top of an asynchronous API if
  they are (a) running in separate threads/processes AND (b) the sync
  thread can synchronously poll (busy loop) for the progress/completion of
  the async thread.

 a) is necessary, but for b) it is sufficient for the sync thread to be
 able to sleep until a condition/mutex/... is lifted


 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla




Re: Sync API for workers

2013-10-13 Thread James Greene
Oh, does `yield` work anywhere? I thought it was only for use within
generators. Admittedly, I haven't been keeping up with the latest ES6
changes.
On Oct 13, 2013 9:38 AM, pira...@gmail.com pira...@gmail.com wrote:

 Javascript now has support for yield statements the same way Python does,
 that's a way to stop (ie. sleep) the execution of a script to allow another
 to work and restart from there. It's not their main function, but allow to
 create what's called greenlets, green threads, and that's how I seen sync
 APIs are build in top of async ones...
 El 13/10/2013 16:21, James Greene james.m.gre...@gmail.com escribió:

  a) is necessary, but for b) it is sufficient for the sync thread to be
  able to sleep until a condition/mutex/... is lifted

 In other words, your clarification is completely true but my initial
 statement was written with regard to client-side JavaScript, which cannot
 sleep. As such, I believe my original assertions are still correct with
 regard to writing a sync wrapper in JS.
 On Oct 13, 2013 9:09 AM, James Greene james.m.gre...@gmail.com wrote:

 Thanks for adding clarification. That CAN be true but it depends on the
 environment [so far as I can see].

 For example, such an API wrapper couldn't be built in today's
 client-side JavaScript because the UI thread can't do a synchronous
 yielding sleep but rather can only do a synchronous blocking wait, which
 means it wouldn't yield to allow for the Worker thread to asynchronously
 respond and toggle such a condition/mutex/etc. unless such can be
 synchronously requested by the blocking thread from within the busy wait
 loop (e.g. `processEvents();`) as browsers won't interrupt the synchronous
 flow of the JS busy loop to trigger `onmessage` handlers for async messages
 sent from the Worker.

 If I'm mistaken, please consider providing a code snippet, gist, etc. to
 get me back on track. Thanks!
 On Oct 13, 2013 5:06 AM, David Rajchenbach-Teller dtel...@mozilla.com
 wrote:

 On 10/12/13 3:48 PM, James Greene wrote:
  You can only build a synchronous API on top of an asynchronous API if
  they are (a) running in separate threads/processes AND (b) the sync
  thread can synchronously poll (busy loop) for the progress/completion
 of
  the async thread.

 a) is necessary, but for b) it is sufficient for the sync thread to be
 able to sleep until a condition/mutex/... is lifted


 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla




Re: Sync API for workers

2013-10-13 Thread James Greene
Rick:
Thanks for confirming that.

Being more familiar with generators (and other ES6 goodies), can you
envision any setup where a generator (or perhaps multiple yielding to each
other) would enable us to build synchronous API wrappers around async APIs
in JS?
On Oct 13, 2013 6:44 PM, Rick Waldron waldron.r...@gmail.com wrote:



 On Sunday, October 13, 2013, James Greene wrote:

 Oh, does `yield` work anywhere? I thought it was only for use within
 generators. Admittedly, I haven't been keeping up with the latest ES6
 changes.


 yield may only appear in the body of a generator function, denoted by star
 syntax: function* g(){}

 Rick



 On Oct 13, 2013 9:38 AM, pira...@gmail.com pira...@gmail.com wrote:

 Javascript now has support for yield statements the same way Python
 does, that's a way to stop (ie. sleep) the execution of a script to allow
 another to work and restart from there. It's not their main function, but
 allow to create what's called greenlets, green threads, and that's how I
 seen sync APIs are build in top of async ones...
 El 13/10/2013 16:21, James Greene james.m.gre...@gmail.com escribió:

  a) is necessary, but for b) it is sufficient for the sync thread to be
  able to sleep until a condition/mutex/... is lifted

 In other words, your clarification is completely true but my initial
 statement was written with regard to client-side JavaScript, which cannot
 sleep. As such, I believe my original assertions are still correct with
 regard to writing a sync wrapper in JS.
 On Oct 13, 2013 9:09 AM, James Greene james.m.gre...@gmail.com
 wrote:

 Thanks for adding clarification. That CAN be true but it depends on
 the environment [so far as I can see].

 For example, such an API wrapper couldn't be built in today's
 client-side JavaScript because the UI thread can't do a synchronous
 yielding sleep but rather can only do a synchronous blocking wait, which
 means it wouldn't yield to allow for the Worker thread to asynchronously
 respond and toggle such a condition/mutex/etc. unless such can be
 synchronously requested by the blocking thread from within the busy wait
 loop (e.g. `processEvents();`) as browsers won't interrupt the synchronous
 flow of the JS busy loop to trigger `onmessage` handlers for async 
 messages
 sent from the Worker.

 If I'm mistaken, please consider providing a code snippet, gist, etc.
 to get me back on track. Thanks!
 On Oct 13, 2013 5:06 AM, David Rajchenbach-Teller 
 dtel...@mozilla.com wrote:

 On 10/12/13 3:48 PM, James Greene wrote:
  You can only build a synchronous API on top of an asynchronous API
 if
  they are (a) running in separate threads/processes AND (b) the sync
  thread can synchronously poll (busy loop) for the
 progress/completion of
  the async thread.

 a) is necessary, but for b) it is sufficient for the sync thread to be
 able to sleep until a condition/mutex/... is lifted


 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla




Re: Sync API for workers

2013-10-12 Thread James Greene
You can only build a synchronous API on top of an asynchronous API if they
are (a) running in separate threads/processes AND (b) the sync thread can
synchronously poll (busy loop) for the progress/completion of the async
thread.
On Oct 12, 2013 1:23 AM, pira...@gmail.com pira...@gmail.com wrote:

  Synchronous APIs are easier to use since it's how things have been done
 since decades ago,
 
 
  No, they're easier to use because they fit the model of linear human
 thought more naturally.  The idea that asynchronous APIs are just as good
 and easy as synchronous APIs, and that people only disagree because of lack
 of experience with asynchronous APIs, is mistaken.  APIs must be designed
 around how programmer's minds actually work, not how you'd like them to
 work.
 
 I agree that APIs should have the least-surprise-factor, but are you sure
 that's the reason why we use to program in a synchronous, linear way?
 Because I've always though it was an heritage of the batch-processing
 machines of the '60s... I don't believe event-oriented programming fit bad
 with how humans thinks because the nature is event-oriented (if this then
 that), and I don't believe I'm an alien so that's the reason I think in a
 different way...

  but the required POSIX-like APIs would be better developed as external
 libraries on top of the asynchronous ones.
 
  You can't build synchronous APIs on top of asynchronous APIs without the
 mechanism this thread is specifically about.
 
 I've always been taught that you can implement one on top of the other...
 :-/ Obviously, asynchronous on top of synchronous is fairly easier thsn in
 the other way...



Re: [XHR] Content-Length header for data: URLs

2013-09-19 Thread James Greene
XHRs for `mailto:`? :)

Kidding, though that would be kind of interesting.
On Sep 19, 2013 6:28 PM, Jonas Sicking jo...@sicking.cc wrote:

 That's true for img src=data:... too. Technically that's also not
 needed. Same with img src=blob:...

 I think there's a lot of value in ensuring that all URL schemes work
 in all APIs that handle URLs. Otherwise the concept of a URL sort of
 falls apart.

 / Jonas

 On Thu, Sep 19, 2013 at 2:46 PM, pira...@gmail.com pira...@gmail.com
 wrote:
  Are you saying it's possible to use 'data:' requests with XHR? What's
  the sense for this? The data is already on the client...
 
  2013/9/19 Hallvord Steen hst...@mozilla.com:
  Hi,
  I see Gecko fakes a Content-Length header (visible to
 getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong
 per the spec (which is explicitly requiring only a single Content-Type
 response header) but it looks more like a feature than a bug.. Should we
 spec it?
 
  Test:
 http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/data-uri-basic.htm(subtest
  getAllResponseHeaders())
  Current spec text:
 http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http
  -Hallvord R
 
 
 
 
  --
  Si quieres viajar alrededor del mundo y ser invitado a hablar en un
  monton de sitios diferentes, simplemente escribe un sistema operativo
  Unix.
  – Linus Tordvals, creador del sistema operativo Linux
 




Re: [XHR] Content-Length header for data: URLs

2013-09-19 Thread James Greene
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length would likely
exclude the comma and prior.  Does that make sense to others?

Sincerely,
James Greene



On Thu, Sep 19, 2013 at 11:10 PM, Julian Aubourg j...@ubourg.net wrote:

 It's a malformed data URI for now. What I'm wondering is if we're sure
 we'll never have an encoding that makes it impossible to determine the
 length without decoding the entire content (think url-encoded like).

 I do agree having the Content-Length is useful information, I'm just
 trying to make sure we're future-proof in our approach.

 My opinion is that a Content-Length should be provided but I'm not sure
 it must. And again, since Anne doesn't seem to favour should... well,
 we're back at must not.


 On 20 September 2013 05:55, Boris Zbarsky bzbar...@mit.edu wrote:

 On 9/19/13 11:39 PM, Julian Aubourg wrote:

 We need to check the encoding


 You mean the base64 or lack thereof?


  we need to make sure we
 know how to determine the actual length for this encoding


 For base64 you do.  Otherwise, it's a malformed data URI.


  we need a way
 to not store length if we dunno the encoding


 In what situation would this ever happen?


  What I'm seeing here is that being able to have a Content-Length or not
 seems implementation dependent.


 No more so than having a Content-Type, as far as I can see.


  I'm pretty sure we cannot assume all implementations will be able to
 provide a Content-Length.


 I'm pretty sure we can in fact assume just that.


  So it seems like we should just keep
 prohibiting Content-Length.


 If it were useless to provide it, I might agree.  But it's useful.  This
 is why blob URIs go out of their way to provide it...

 -Boris





Re: [clipboard] typo in WebIDL

2013-09-18 Thread James Greene
Remember that the URL referenced is not for the latest version of this
spec. Correct URL:
   http://www.w3.org/TR/clipboard-apis/
On Sep 18, 2013 8:54 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, Sep 18, 2013 at 9:05 AM, Hallvord Steen hst...@mozilla.com
 wrote:
  At some point I started using respec.js and switched to whatever
 convention the respec version I was using used for IDL snippets. I may have
 to sit down and understand if I've done that correctly, or if I've done
 something incompatible with tools that extract IDL from specs.. Not sure
 how the stuff that goes into Gecko source code gets extracted.

 Unless ClipboardEvent can be created via document.createEvent() (per
 current specs it cannot) you want to have default values in the init
 dictionary.


 --
 http://annevankesteren.nl/




Re: [clipboard] typo in WebIDL

2013-09-18 Thread James Greene
Understood, just making sure we're pointed at the right spec.

For some reason, Google search results can't seem to shake that old spec in
favor of the new one.  The new spec doesn't even make the first 5 pages of
results for me when I search clipboard api or html|html5 clipboard api.
 :-\

It does show up as the top result for me if I search clipboard spec or
html|html5 clipboard spec, though.

Sincerely,
James Greene



On Wed, Sep 18, 2013 at 10:14 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 9/18/13 10:09 AM, James Greene wrote:

 Remember that the URL referenced is not for the latest version of this
 spec. Correct URL:
 http://www.w3.org/TR/**clipboard-apis/http://www.w3.org/TR/clipboard-apis/


 Again, this has no IDL for the dictionary at all.  That's clearly wrong.

 -Boris




Re: [clipboard] typo in WebIDL

2013-09-18 Thread James Greene
I'm lost. Is there an explanation of this somewhere?
On Sep 18, 2013 10:42 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, Sep 18, 2013 at 10:09 AM, James Greene james.m.gre...@gmail.com
 wrote:
  Remember that the URL referenced is not for the latest version of this
 spec.
  Correct URL:
 http://www.w3.org/TR/clipboard-apis/

 If the URL includes TR/, it's not the correct URL.


 --
 http://annevankesteren.nl/



Re: [clipboard] typo in WebIDL

2013-09-18 Thread James Greene
So does this imply that someone (i.e. Hallvord :)) needs to move it
elsewhere?

Sincerely,
James Greene



On Wed, Sep 18, 2013 at 12:17 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Wed, Sep 18, 2013 at 10:06 AM, James Greene james.m.gre...@gmail.com
 wrote:
  On Sep 18, 2013 10:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
  On Wed, Sep 18, 2013 at 10:09 AM, James Greene 
 james.m.gre...@gmail.com
  wrote:
   Remember that the URL referenced is not for the latest version of this
   spec.
   Correct URL:
  http://www.w3.org/TR/clipboard-apis/
 
  If the URL includes TR/, it's not the correct URL.
 
  I'm lost. Is there an explanation of this somewhere?

 Things on /TR have a very strong precedent of being drastically
 out-of-date and riddled with errors, because the W3C publication
 process is still painful enough (and used to be even more painful)
 that it's annoying to publish consistently.  You should nearly always
 be looking at the Editor's Drafts instead - thus the refrain TR is
 short for TRash.

 ~TJ



Re: Why the clipboard API needs copy/paste event simulation as a permission option

2013-09-14 Thread James Greene
We've discussed enabling click-to-copy in another thread (
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0061.html and
beyond) and have agreed that it is an acceptable risk.

When I started the thread, I had also mentioned requesting site-wide user
permissions as an option (e.g. like the Geolocation API) but, again, it was
deemed irrelevant as allowing click-to-copy out-of-the-box is now
considered an acceptable risk.

Generally speaking, I think what you are proposing would be so fantastic
for testing purposes but that it is generally overshooting a bit for normal
users.  Perhaps requesting side-wide permissions would be a sufficient
compromise to getting that approved, though?  I'm not positive.  One thing
that would be nicer about pursuing such a route in the HTML5 Clipboard API
world vs. the security uproar that resulted when Flash 9 allowed unprompted
clipboard injection is that this could legitimately be restricted to just
the site domains, thus avoiding having annoying ads from another domain
injecting into your clipboard.

Thoughts from others?

Sincerely,
James Greene



On Wed, Aug 7, 2013 at 12:34 PM, James Babcock jimrand...@gmail.com wrote:

 Currently, the clipboard API allows Javascript to read the clipboard
 in response to a paste event (in most UAs, that's when the user types
 Ctrl+V or picks Paste from the default context menu); and it lets JS
 write to the clipboard in response to a copy event (when the user
 types Ctrl+C or picks Copy from the default context menu). Generating
 these events with document.execCommand is disallowed for security
 reasons, because of concerns about clipboard stealing and clipboard
 poisoning: someone might write a script that watches the clipboard for
 things that look like passwords and steals them, or for things that
 look like shell commands and replaces them with something nasty. This
 is a legitimate concern, but there really needs to be a way to grant
 pages permission to access the clipboard. To see why this is
 important, observe:

 In Google Docs, if you pick Copy or Paste from its menu or a context
 menu, it prompts you to install a plugin.

 This is a particularly conspicuous example, but it's not the only one.
 Anything that wants to replace the default context menu is faced with
 a dilemma: most browsers' default context menu has cut/copy/paste
 options on it, but a replacement context menu can't. Another case
 where it's a problem is in browser-based ssh clients, where Ctrl+C is
 not available as a hotkey for copy, but copy/pasting is nevertheless
 very important (so important, in fact, that many terminals copy to the
 clipboard on text-select without any keystroke at all). This is a
 problem for one of my side-projects (a browser-based extended
 terminal), and a fairly serious one, so I'd like to see this resolved;
 I don't want to have to include a plugin and only support one browser.

 (For my particular application, I would strongly prefer that the
 access permission not be limited to responding to input events,
 because I'm working in a programming model where the client page is a
 stub that sends DOM events and receives DOM mutations, so the state
 necessary to fill the clipboard, and to determine which keystrokes
 correspond to copy/paste events, all lives on the server side.
 Limiting access to times when the tab is visible and the window is
 focused is fine, though.)





Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-09-13 Thread James Greene
Excellent.  Thank you!

Should we be including touch device events, too?  e.g. touchend,
pointerup, etc.

Sincerely,
James Greene



On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen hst...@mozilla.com wrote:

  AFAIK Flash shipped with a more liberal model first, but the abuse
 problem
  was considered significant enough to tighten the model and make it more
  restrictive.

  That's correct:
- In Flash 9, you could use the
  `System.setClipboard
 http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
  /System.html#setClipboard()`

 Thanks for outlining the history and documentation. I think we should give
 authors (at least) the same convenience as Flash does. Reported here:
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

 -Hallvord (in I will try to get around to actually updating the spec
 too-mode)



Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-09-13 Thread James Greene
Also, will there be any way for us to feature detect when this is available?

I'm thinking that just using `document.queryCommandSupported(copy)` and
`document.queryCommandEnabled(copy)` could return some false positives
(i.e. the feature is not yet implemented but returns `true` anyway) when
the user is working within a contenteditable element, right?

Sincerely,
James Greene



On Fri, Sep 13, 2013 at 10:10 AM, James Greene james.m.gre...@gmail.comwrote:

 Excellent.  Thank you!

 Should we be including touch device events, too?  e.g. touchend,
 pointerup, etc.

 Sincerely,
 James Greene



 On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen hst...@mozilla.comwrote:

  AFAIK Flash shipped with a more liberal model first, but the abuse
 problem
  was considered significant enough to tighten the model and make it more
  restrictive.

  That's correct:
- In Flash 9, you could use the
  `System.setClipboard
 http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
  /System.html#setClipboard()`

 Thanks for outlining the history and documentation. I think we should
 give authors (at least) the same convenience as Flash does. Reported here:
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

 -Hallvord (in I will try to get around to actually updating the spec
 too-mode)





Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-26 Thread James Greene

 AFAIK Flash shipped with a more liberal model first, but the abuse problem
 was considered significant enough to tighten the model and make it more
 restrictive.


That's correct:

   - In Flash 9, you could use the
`System.setClipboardhttp://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.html#setClipboard()`
   method to write to the user's clipboard without *ANY* user interaction
   whatsoever.
  - This led to some security uproar about malicious clipboard
poisoninghttps://www.google.com/search?q=flash+9+clipboard+poisoning,
  especially since many of the SWFs that people created passed the text to
  inject via URL params, thus allowing XSS attacks to easily inject into
  someone's clipboard just by requesting their SWF resource with the right
  URL params.
  - Unsurprisingly, the uptake in Flash-based ads were a huge
  contributor to the problem back then.

  - In Flash 10+, Adobe locked
downhttp://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes.html#head31the
`System.setClipboard` method and the [then] new `
   
flash.desktop.Clipboardhttp://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html`
   class a bit more such that clipboard interactions (including settings and
   clearing) could *ONLY* be performed as a *synchronous *operation
   immediately following a user's click or keyboard event.
  - This also means that you cannot use async XHRs for fetching the
  data to inject; while it is unfortunate to have to use sync XHRs instead,
  the synchronous flow is obviously very important for the security of the
  user's clipboard.


If you look at the Flash docs I've linked to, it's important to notice when
they differentiate between when the context of Adobe AIR (where there are
no such clipboard restrictions) and Adobe Flash Player (where there are).



Sincerely,
James Greene



On Fri, Jul 26, 2013 at 9:37 AM, Hallvord Steen hst...@mozilla.com wrote:

  leaving it up to the browser vendors WITHOUT an agreed upon
  standard (or at least marching direction) means zero progress.

 I'd argue that the spec gives a marching direction, but I'd like to pass
 a simple question on to the implementors and the security/privacy experts
 around here:

 Should we allow document.execCommand('copy') on all sites by default?

 Pro arguments include: web apps and sites can offer copy to clipboard
 functionality without Flash hacks. We avoid reliance on yellow warnings,
 which seem destined to be used for so many APIs over time that the user
 will be annoyed and maybe start automatically clicking yes. It's probably
 good in general to reduce the number of separate privileges web authors
 need to worry about having or not having, by omitting privilege
 requirements for the less risky actions.

 Contra arguments include: being able to write to clipboard can be abused
 to cause nuisance, in that every page you load can overwrite what's on your
 clipboard. Such behaviour could and should be self-defeating for a web site
 that wants to have return visitors, but in this case it may be hard to
 figure out exactly which website caused the issue, since clipboard entry
 meta data like originating URL is normally not available to users. (One
 might imagine a site placing ad copy for some service on your clipboard,
 but the perceived nuisance, data loss and annoyance would make it a very
 poor ad channel indeed). AFAIK Flash shipped with a more liberal model
 first, but the abuse problem was considered significant enough to tighten
 the model and make it more restrictive.


 -Hallvord



Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread James Greene
Paul:

Looking at TimBL's 2010 post, I feel like it's from a slightly era in the
web's lifetime.  Looking at this problem again with today's web, I'd rather
see the ability for clipboard injection become a standard available API and
rather create a browser extension to *prevent* it rather than to *enable* it.
 To me, it's reminiscent of the discussion that probably occurred when the
ability to create popup windows was first introduced, and then AdBlock (and
similar apps, browser extensions, etc.) were soon to follow.

Hell, I'd be happy to write some of the extensions myself if it helps push
my agenda.  ;)


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 3:22 PM, Paul Libbrecht p...@hoplahup.net wrote:


 James,

 I personally think it would be a really good idea. But I am not a browser
 implementor.

 Overall, I agree with you that writing to the clipboard, only within a
 click or key event processing maybe?, is likely to be a non-concern on
 privacy. I would love to hear others' feedback.

 Is maybe a first step something such as a browser-extension?
 Did you hear brags about users of websites that allowing copy was not a
 good idea?

 (I heard a brag close to it by TimBL and J Gruber about the usage of
 clipboard injection:
 http://lists.w3.org/Archives/Public/www-tag/2010Jun/0007.html are we
 close to that? I think not but maybe can such a feature get close to it?)

 Paul

 On 12 juil. 2013, at 21:57, James Greene wrote:

 It appears that the only way to trigger a `copy` event programmatically
 is to use `document.execCommand('copy')`, which most browsers prevent:

 http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

 What about enabling so enabling semi-restricted programmatic clipboard
 injection on a page if the user grants their express permission via a
 once-per-domain security prompt (similar to the Geolocation API)?  IOW,
 given a user's express permission to the origin and following a user's
 pointer event or keyboard interaction, I would like to be able to simulate
 the `copy` event (and the `beforecopy` event, if practical).

 I'm not quite sure how far this will go as clipboard poisoning is always
 a real concern.  In fact, I understand that better than most, since my desire
 to get such an adaptation to the Clipboard API spec is the direct result of
 my work as the co-maintainer of the popular 
 ZeroClipboardhttps://github.com/zeroclipboard/ZeroClipboard library
 (used by GitHub, bit.ly, and many other sites).  Jon and I would like
 nothing better than to eliminate ZeroClipboard's dependency on 
 Flashhttps://github.com/zeroclipboard/ZeroClipboard/issues/171 but
 that is unattainable given the current restrictions of this spec.

 If Flash doesn't live on for anything else, it may well live on longer
 than it should for its unmatched ability to do programmatic clipboard
 injectionhttp://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()
  after
 a user's click or keypress.  :(

 Thoughts?


 Sincerely,
 James Greene
 http://jamesgreene.net/





Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread James Greene
Hallvord —
I have also long agreed that clipboard poisoning is rarely that big of an
issue so long as we're not enabling programmatic reading of the clipboard
during a copy event (which I would agree is completely unnecessary).  As
you said, since Flash is already an available option to do this today (and
can thus only be prevented by disabling Flash, or enforcing specialized
clipboard sandboxing at a system level), moving it into the DOM world isn't
a big stretch by any means.

I also agree that making this ability the default is not unreasonable
anymore but I thought that might be a bit of a stretch... happy to see that
I am wrong. :)


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 5:34 PM, Hallvord Steen hst...@mozilla.com wrote:

 [Replying to Paul's mail but it's really a response to James - sorry,
 Paul..]

 On 12 juil. 2013, at 21:57, James Greene wrote:

  It appears that the only way to trigger a `copy` event programmatically
 is to use `document.execCommand('copy')`, which most browsers prevent:
 
 http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

 Correct.

  What about enabling so enabling semi-restricted programmatic clipboard
 injection on a page
  if the user grants their express permission via a once-per-domain
 security prompt (similar
  to the Geolocation API)?

 Well, with my spec editor's hat on: Nothing really prevents UAs from
 implementing this already. They could hook up document.execCommand('Copy')
 to whatever that UA's convention for a security permission prompt is. I'd
 like to see this, actually.

 That said, this functionality doesn't really have privacy implications (as
 long as it is about programmatically *writing to*, not *reading from* the
 clipboard) so it's mostly just about preventing nuisance, plus some
 slightly far-fetched security threats (which aren't all that credible if
 they are not already exploited with Flash's clipboard implementation). Our
 intentions as implementors has sort of moved towards enabling all the cool
 stuff apps and sites might do, and away from trying to control nuisance.
 It's quite possible to argue that writing to the clipboard should be
 enabled by default.
 -Hallvord



Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread James Greene
Ryosuke  Anne —
Agreed with Anne, leaving it up to the browser vendors an agreed upon
standard (or at least marching direction) means zero progress.


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 7:32 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Jul 12, 2013, at 12:57 PM, James Greene james.m.gre...@gmail.com
 wrote:
  It appears that the only way to trigger a `copy` event programmatically
 is
  to use `document.execCommand('copy')`, which most browsers prevent:
 
 
 http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

 On Wed, Jul 24, 2013 at 5:18 PM, Ryosuke Niwa rn...@apple.com wrote:
  I don't want the clipboard API specification to mandate one behavior or
  another.  It's something each browser vendor should be able to decide.

 That's the situation we are in now and it sucks for developers. We
 should be able to do better.


 --
 http://annevankesteren.nl/



Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread James Greene
Oh, and for the record, the analytics company discussed in the Tim BL's
post could've really still manage to do what they were doing without any
copy events at all, it just would've been less accurate.

For example, they could've just as easily added event handlers for
right-click (contextmenu) or Ctrl+C keypresses when there is an active text
selection and make the assumption that the user intended to copy that text.
 They might be wrong some of the time with the right-click handling but it
would still be factual that the user at least had a special interest in the
text selection.

I actually think that kind of analytics is awesome — so long as it isn't
being used for evil, of course.  :)

Sincerely,
James Greene



On Wed, Jul 24, 2013 at 8:07 PM, James Greene james.m.gre...@gmail.comwrote:

 Paul:

 Looking at TimBL's 2010 post, I feel like it's from a slightly era in the
 web's lifetime.  Looking at this problem again with today's web, I'd rather
 see the ability for clipboard injection become a standard available API and
 rather create a browser extension to *prevent* it rather than to *enable* it.
  To me, it's reminiscent of the discussion that probably occurred when the
 ability to create popup windows was first introduced, and then AdBlock (and
 similar apps, browser extensions, etc.) were soon to follow.

 Hell, I'd be happy to write some of the extensions myself if it helps push
 my agenda.  ;)


 Sincerely,
 James Greene



 On Wed, Jul 24, 2013 at 3:22 PM, Paul Libbrecht p...@hoplahup.net wrote:


 James,

 I personally think it would be a really good idea. But I am not a browser
 implementor.

 Overall, I agree with you that writing to the clipboard, only within a
 click or key event processing maybe?, is likely to be a non-concern on
 privacy. I would love to hear others' feedback.

 Is maybe a first step something such as a browser-extension?
 Did you hear brags about users of websites that allowing copy was not a
 good idea?

 (I heard a brag close to it by TimBL and J Gruber about the usage of
 clipboard injection:
 http://lists.w3.org/Archives/Public/www-tag/2010Jun/0007.html are we
 close to that? I think not but maybe can such a feature get close to it?)

 Paul

 On 12 juil. 2013, at 21:57, James Greene wrote:

 It appears that the only way to trigger a `copy` event programmatically
 is to use `document.execCommand('copy')`, which most browsers prevent:

 http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

 What about enabling so enabling semi-restricted programmatic clipboard
 injection on a page if the user grants their express permission via a
 once-per-domain security prompt (similar to the Geolocation API)?  IOW,
 given a user's express permission to the origin and following a user's
 pointer event or keyboard interaction, I would like to be able to simulate
 the `copy` event (and the `beforecopy` event, if practical).

 I'm not quite sure how far this will go as clipboard poisoning is
 always a real concern.  In fact, I understand that better than most, since
 my desire to get such an adaptation to the Clipboard API spec is the
 direct result of my work as the co-maintainer of the popular
 ZeroClipboard https://github.com/zeroclipboard/ZeroClipboard library
 (used by GitHub, bit.ly, and many other sites).  Jon and I would like
 nothing better than to eliminate ZeroClipboard's dependency on 
 Flashhttps://github.com/zeroclipboard/ZeroClipboard/issues/171 but
 that is unattainable given the current restrictions of this spec.

 If Flash doesn't live on for anything else, it may well live on longer
 than it should for its unmatched ability to do programmatic clipboard
 injectionhttp://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()
  after
 a user's click or keypress.  :(

 Thoughts?


 Sincerely,
 James Greene
 http://jamesgreene.net/






Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-24 Thread James Greene
*Correction:*
leaving it up to the browser vendors WITHOUT an agreed upon standard (or at
least marching direction) means zero progress.


Sincerely,
James Greene



On Wed, Jul 24, 2013 at 8:11 PM, James Greene james.m.gre...@gmail.comwrote:

 Ryosuke  Anne —
 Agreed with Anne, leaving it up to the browser vendors an agreed upon
 standard (or at least marching direction) means zero progress.


 Sincerely,
 James Greene



 On Wed, Jul 24, 2013 at 7:32 PM, Anne van Kesteren ann...@annevk.nlwrote:

 On Jul 12, 2013, at 12:57 PM, James Greene james.m.gre...@gmail.com
 wrote:
  It appears that the only way to trigger a `copy` event programmatically
 is
  to use `document.execCommand('copy')`, which most browsers prevent:
 
 
 http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

 On Wed, Jul 24, 2013 at 5:18 PM, Ryosuke Niwa rn...@apple.com wrote:
  I don't want the clipboard API specification to mandate one behavior or
  another.  It's something each browser vendor should be able to decide.

 That's the situation we are in now and it sucks for developers. We
 should be able to do better.


 --
 http://annevankesteren.nl/





Re: Clipboard API: Default content in copy/cut handlers

2013-07-12 Thread James Greene
Right, I think this makes total sense.  A common example might be to add
your page's URL, copyright notice, etc. to the end of whatever text the
user has selected WITHOUT having to query the Selection/Range APIs to
[hopefully] retrieve their selected text.

I am discouraged, however, to see someone who works for a browser vendor
lamenting that doing it in what is likely the right way may be impossible
because a number of browser vendors have already implemented the
functionality.  To me, it doesn't really seem like adding this new behavior
would negatively affect the current APIs at all as no one is *expecting* to
have that data provided on the Event right now; the only real change here
is in the browser internals, and consumers can take advantage of such by
eliminating their current Selection/Range queries once the Event is
providing that data on their behalf.

As someone who is not a browser vendor employee, this sounds very doable.
 ;)

Sincerely,
James Greene



On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng dch...@google.com wrote:

 On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht p...@hoplahup.net
 wrote:
  Is there any reason to justify the requirement to populate before the
 dragstart?

 My guess is that it's a convenience for authors to be able to modify
 the content from the default easily.

 On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen
 hallv...@opera.com wrote:
  Regarding the question: I'm not sure what exactly you're asking for with
  something similar and what effect it would have. Is it about reading
 from
  clipboard (for example, since you mention  DnD of files, like reading
 pasted
  file references in a paste event)? Writing to the clipboard? Is there any
  change the clipboard spec should make to make pasting files/folders
 easier
  to implement? If yes, how and why?

 My original idea is that prior to dispatching a copy/cut event, run
 if there is a selection, place the contents of the selection in the
 data store, then dispatch the copy/cut event.

 If the copy/cut event is not cancelled, then:
 - Write the data store to the clipboard.

 If the copy/cut event is cancelled:
 - Do nothing. The data store is discarded and the changes are not
 written to the clipboard.

 Unfortunately, this is completely opposite of how it's handled today
 by Firefox/Chrome/Safari so I don't think we can do this. Oh well.

 Daniel




Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-07-12 Thread James Greene
It appears that the only way to trigger a `copy` event programmatically is
to use `document.execCommand('copy')`, which most browsers prevent:

http://www.w3.org/TR/clipboard-apis/#integration-with-other-scripts-and-events

What about enabling so enabling semi-restricted programmatic clipboard
injection on a page if the user grants their express permission via a
once-per-domain security prompt (similar to the Geolocation API)?  IOW,
given a user's express permission to the origin and following a user's
pointer event or keyboard interaction, I would like to be able to simulate
the `copy` event (and the `beforecopy` event, if practical).

I'm not quite sure how far this will go as clipboard poisoning is always
a real concern.  In fact, I understand that better than most, since my desire
to get such an adaptation to the Clipboard API spec is the direct result of
my work as the co-maintainer of the popular
ZeroClipboardhttps://github.com/zeroclipboard/ZeroClipboard library
(used by GitHub, bit.ly, and many other sites).  Jon and I would like
nothing better than to eliminate ZeroClipboard's dependency on
Flashhttps://github.com/zeroclipboard/ZeroClipboard/issues/171 but
that is unattainable given the current restrictions of this spec.

If Flash doesn't live on for anything else, it may well live on longer than
it should for its unmatched ability to do programmatic clipboard
injectionhttp://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()
after
a user's click or keypress.  :(

Thoughts?


Sincerely,
James Greene
http://jamesgreene.net/


Re: Clipboard API: Default content in copy/cut handlers

2013-07-12 Thread James Greene
Sorry, I think I must've misunderstand what your original proposed changes
were as I thought you meant that the DataTransfer interface's items weren't
being pre-populated on the ClipboardEvent's clipboardData property for
beforecopy/copy events.  Now I'm thinking that THAT is already in place and
you are just suggesting a change in what is considered the default behavior
once there is a registered listener for the beforecopy/copy event(s).

Node.js does a similar behavioral switch-up for uncaught exceptions.
 Normally an uncaught exception results in printing the stack trace and
then exiting the process; however, if you add a listener for the
`uncaughtException`
event http://nodejs.org/api/process.html#process_event_uncaughtexception,
then this default behavior will NOT happen and it's left up completely to
the handler to choose whether to print a stack trace, exit the process, etc.

Sincerely,
James Greene



On Fri, Jul 12, 2013 at 3:07 PM, Daniel Cheng dch...@google.com wrote:

 The problem is backwards compatibility. There are sites that use the
 copy/cut event handler, and the proposal reverses the behavior.
 Suppose it were implemented:

 On older browsers: You must call event.preventDefault() in order for
 your changes to be written to the clipboard.
 On newer browsers: You must NOT call event.preventDefault() in order
 for your changes to be written to the clipboard.

 This transition would be extremely confusing, even if the proposal
 does seem more intuitive =/

 Daniel

 On Fri, Jul 12, 2013 at 12:20 PM, James Greene james.m.gre...@gmail.com
 wrote:
  Right, I think this makes total sense.  A common example might be to add
  your page's URL, copyright notice, etc. to the end of whatever text the
 user
  has selected WITHOUT having to query the Selection/Range APIs to
 [hopefully]
  retrieve their selected text.
 
  I am discouraged, however, to see someone who works for a browser vendor
  lamenting that doing it in what is likely the right way may be
 impossible
  because a number of browser vendors have already implemented the
  functionality.  To me, it doesn't really seem like adding this new
 behavior
  would negatively affect the current APIs at all as no one is expecting to
  have that data provided on the Event right now; the only real change
 here is
  in the browser internals, and consumers can take advantage of such by
  eliminating their current Selection/Range queries once the Event is
  providing that data on their behalf.
 
  As someone who is not a browser vendor employee, this sounds very doable.
  ;)
 
  Sincerely,
  James Greene
 
 
 
 
  On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng dch...@google.com wrote:
 
  On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht p...@hoplahup.net
  wrote:
   Is there any reason to justify the requirement to populate before the
   dragstart?
 
  My guess is that it's a convenience for authors to be able to modify
  the content from the default easily.
 
  On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen
  hallv...@opera.com wrote:
   Regarding the question: I'm not sure what exactly you're asking for
 with
   something similar and what effect it would have. Is it about reading
   from
   clipboard (for example, since you mention  DnD of files, like reading
   pasted
   file references in a paste event)? Writing to the clipboard? Is there
   any
   change the clipboard spec should make to make pasting files/folders
   easier
   to implement? If yes, how and why?
 
  My original idea is that prior to dispatching a copy/cut event, run
  if there is a selection, place the contents of the selection in the
  data store, then dispatch the copy/cut event.
 
  If the copy/cut event is not cancelled, then:
  - Write the data store to the clipboard.
 
  If the copy/cut event is cancelled:
  - Do nothing. The data store is discarded and the changes are not
  written to the clipboard.
 
  Unfortunately, this is completely opposite of how it's handled today
  by Firefox/Chrome/Safari so I don't think we can do this. Oh well.
 
  Daniel