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

On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard <> 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.
I think these are from ReSpec.js 's bibliographic database actually.

On Fri, May 23, 2014 at 8:21 AM, James Greene <> wrote:
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:
// Copy HTML text:
span = document.createElement("span");
span.innerHTML = "<b>hello</b>";
// Copy an image from a CanvasImageSource:
// Copy the selection:
// Copy HTML text with plaintext alternative:
dt = new DataTransferItemList();
dt.add("hello", "text/plain");
dt.add(span.innerHTML, "text/html");

This looks like a pretty usable API to me. One of the main simplifications is that it drops certain limitations that we've added to "lock down" the API - for example the way clipboardData and its methods is only available to an event listener's thread. So .. it depends on whether that's what we want.

Re: XMLHttpRequest and timing of upload events

Hi Anne,
sorry to be late at responding - just going through some E-mail I didn't have time to understand and respond to before..

On Tue, May 20, 2014 at 2:55 PM, Anne van Kesteren <annevk <at>> wrote:
Because redirects are atomic, we cannot dispatch loadend events and
such on the XMLHttpRequestUpload class.

Does this change mean we can no longer send 'loadend' on the upload object? How is a script supposed to know when the upload phase is finished, then? Isn't this a functionality we should try to keep - or am I just misunderstanding what you meant here..?

Arthur Barstow | 18 Apr 15:29 2015

[admin] Updating our /TR stylesheets

Below is an announcement about a project "to provide a modern design to 
future technical reports published by the W3C" i.e. updating the 
stylessheet used for Technical Report 
< >.

If you have any feedback, please use 
<> (and do not reply to this thread).

-------- Forwarded Message --------
Subject:     Updating our /TR stylesheets
Date:     Thu, 16 Apr 2015 08:53:21 -0400
From:     Philippe Le Hegaret <plh@...>
To:     spec-prod <spec-prod@...>

I'd like to find a path for W3C to update our /TR style sheets and since
we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been
published in the past, we must not try to do it. It has the
simplification that we're breaking the consistency of style between all
W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead,
I'd like to enable ourselves to have progressive enhancements over the
years. It will also avoid having everyone trying to squeeze their own
ideas between of a once-in-a-lifetime chance to change the styles. To
make it easier on the tooling, we also need something predictable. So,
I'd like to propose that we allow ourselves to update the /TR style
sheets once per year, on January 1. All documents published in that year
would  have to use the style, ensuring some consistency. Note that it
doesn't imply we have to change the style every year, but it gives us an
opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:

Feedback is welcome.


bugzilla | 17 Apr 18:58 2015

[Bug 28505] New: Synchronous XHR removal makes patching Error.prepareStackTrace impossible

            Bug ID: 28505
           Summary: Synchronous XHR removal makes patching
                    Error.prepareStackTrace impossible
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XHR
          Assignee: annevk@...
          Reporter: evan.exe@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

I've got a library that fixes Error.prototype.stack in V8 to work with source
maps because Google refuses to fix this themselves (
However, it's recently come to my attention
( that this is about
to break due to removal of synchronous XHR

Because of the way the API Error.prepareStackTrace API works, I need to fetch
the source map before returning from the callback. I can't know what the URLs
will be ahead of time and fetch them because 1) errors may happen before the
source map download completes and 2) new code with the "//# sourceMappingURL"
pragma can be created with eval at any time.

I understand the goals of removing synchronous XHR but my library legitimately
needs this feature. Breaking this feature will greatly harm debugging for
languages that are cross-compiled to JavaScript. The slowness of synchronous
XHR doesn't matter here because it's just for debugging, not for production

What are people's thoughts on this? Is there maybe some way to add a way in the
spec to still allow synchronous XHR in certain circumstances?


You are receiving this mail because:
You are on the CC list for the bug.

Anne van Kesteren | 17 Apr 07:16 2015

Privileged context features and JavaScript

Soon there will be a number of features that are restricted to
privileged contexts. Most prominent one being service workers.

Within user agents the prevailing pattern is that privileged APIs are
not available in unprivileged contexts. However, both Firefox and
Chrome currently expose the service worker API everywhere, it just
happens to reject.

Should we change this and simply not expose the API in unprivileged
contexts? E.g. through IDL syntax? That way we don't have to carefully
secure all access points.



Glen Huang | 17 Apr 05:34 2015

JSON imports?

Inspired by HTML imports, can we add JSON imports too?

<script type="application/json" src="foo.json" id="foo"></script>
<script type="application/json" id="bar">
{ "foo": "bar" }

document.getElementById("foo").json // or whatever

bugzilla | 17 Apr 01:47 2015

[Bug 28502] New: Add file event watching.

            Bug ID: 28502
           Summary: Add file event watching.
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: File API
          Assignee: arun@...
          Reporter: liamkarlmitchell@...
        QA Contact: public-webapps-bugzilla@...
                CC: public-webapps@...

It would be quite nice if there was the ability to get events from the os when
a file has been modified/updated/deleted.

A possible use case might be an online resource editor, where a user drag drops
the folder full of resources they wish to view and edit.

But if one of the files the browser has access to is edited in another program
on their computer (Example photoshop, paint, notepad etc) the javascript
application could then receive an event for the file change and update the
content/reload file as necessary.

Currently I think the only way to do this is to poll the file.lastModifiedDate

Which sure I guess could be used but its not as optimal as listening for events
given by the OS would be.


You are receiving this mail because:
You are on the CC list for the bug.

Arthur Barstow | 16 Apr 19:13 2015

PSA: publishing new WD of Clipboard APIs and events on April 21

Hi All,

A new Working Draft publication of Clipboard APIs and events is planned 
for April 21 using the following version as the basis:


If anyone has any major concerns about this, please reply right away.

A few notes about this spec:

* This spec is now using Github <> 
and the ED is now <>. PRs are 
welcome and encouraged.

* The permissions of the spec's now obsolete CVS repository will be set 
to read-only.

* After the open Bugzilla bugs [1] are copied to Github Issues (or the 
last open Bugzilla bug is closed), the spec's Bugzilla component will be 
marked `Historical` and set to read-only.

-Thanks, ArtB


Jeremy Scheff | 16 Apr 00:04 2015

Are there any plans to make IndexedDB and promises play nice?

Currently, wrapping IndexedDB in promises is a perilous task. Pun intended, since the sticking point seems to be the distinction between microtasks and macrotasks. See for an example. Basically, it's not clear whether resolving a promise should auto-commit a transaction or not. Behavior varies across browsers and promise libraries, and I don't even know what the "correct" behavior actually is.

Although having the IndexedDB API completely redone in promises would be nice, I understand that may be too big of a change to be feasible. That's fine. All I really would like is for there to be some way to wrap the event-based API in promises without things breaking.

So what's the current status of IndexedDB and promises? Is there any hope that they will work well together in the near future?

Jeremy Scheff
Travis Leithead | 16 Apr 06:37 2015

[Imports] Considering imperative HTML imports?

Was an imperative form of HTML imports already considered? E.g., the following springs to mind:

  Promise<Document> importDocument(DOMString url);


I was thinking about Worker’s importScripts(DOMString… urls), and the above seems like a nice related corollary.

bugzilla | 16 Apr 00:43 2015

[Bug 28496] New: Allow Blob constructor to take ownership of ArrayBuffer(View) / invoke DetachArrayBuffer

            Bug ID: 28496
           Summary: Allow Blob constructor to take ownership of
                    ArrayBuffer(View) / invoke DetachArrayBuffer
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
          Assignee: arun@...
          Reporter: bugmail@...
        QA Contact: public-webapps-bugzilla@...
                CC: public-webapps@...

Motivation: For the Firefox OS email app when we download attachments we end up
with a lot of TypedArray instaces piling up that exist only to be wrapped into
a Blob and then forgotten.  Lacking any way to neuter ArrayBuffers directly, it
would be nice if the Blob could takeownership of them as we pass them in.

Arguably it could be considered a common data-flow to create some data with a
TypedArray and then stuff it in a Blob to store it somewhere

- I guess the 2-step process of "new Blob(takingOwnership).close()" could end
up as a disturbingly hacky general purpose means of disposing of the contents
of TypedArrays.

Mitigation strategies:
- In our specific case we are using the proprietary-mozTCPSocket that just
throws typed arrays at us, but I understand the Streams API provides a
mechanism to allow reads into existing buffers.  APIs that allow use of
existing buffers won't suffer from the "oh no, so many ArrayBuffers!" problem.
- GC will catch the stuff eventually.  Just crank up the GC.


You are receiving this mail because:
You are on the CC list for the bug.