Re: [whatwg] Password managers ignoring autocomplete='off' harming security

[Daniel Cheng]

On Oct 1, 2014 4:34 PM, "Gavin Sharp"  wrote:
>
> Firefox developer here (I was involved in our behavior change). Sorry
> to hear that it's causing you trouble. Unfortunately this seems like a
> pretty specific, uncommon use case, so we hadn't considered it. And we
> probably aren't reasonably able to fix things for you without breaking
> other more common use cases we care about (people using password
> fields for passwords).
>
> The underlying use case seems to be obfuscating text in an input field
> that isn't a password. From a spec perspective, a feature to opt-in to
> obfuscation that isn't type=password could address this (e.g.
> type="masked-text"). From your perspective, I suppose you could work
> around this by obfuscating the text in the field yourself rather than
> letting the browser do it.
>
> Gavin

Doesn't adding this new input type defeat the whole point of ignoring
autocomplete=off? Now sites that want to disable password managers will
just use this for their password field, and we're back to square one.

Daniel

>
> On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski  wrote:
> > Hi All,
> >
> > Over the past few months all the browser vendors have moved towards
> > ignoring autocomplete="off" with password fields. I understand the
> > rationale behind this, but in our software project this has lead to
> > the frustrating situation where we seem to have no good option to deal
> > with this and the change is actively harming the security of our
> > users.
> >
> > To outline the situation in broad terms:
> > * We have shared secrets on the page which we protect against shoulder
> > surfing by using the password element with autocomplete="off"
> > * The password managers are now all auto-filling these fields with
> > passwords on the same domain and in many cases without the user even
> > noticing (optional fields they wouldn't look at)
> > * The passwords then get stored in our shared-secret fields clear text
> > and available to all their peers
> > * This can then be used for privilege escalation etc
> >
> > It seems like our only option is avoid use of password field at all
> > and invent our own 'fake' password field to protect our users
> > passwords from being exposed. That seems like a really disappointing
> > solution.
> >
> > (Apologies in advance if this is completely off-list, I saw some
> > threads leading to this list and it wasn't clear to me if this sort of
> > discussion was acceptable).
> >
> > cheers,
> > Dan

Re: [whatwg] Fullscreen API and out-of-process

[Daniel Cheng]

Either:

1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It shouldn't be surprising that racing operations like this cross
origin returns a non-deterministic result. This is the position the Chrome
out-of-process team is taking for other sorts of actions that have effects
visible outside the frame (for example, navigating the top level frame,
multiple frames sending a postMessage to the same frame, etc).

2) One frame calls requestFullscreen() and then sends a postMessage() to
another frame, which calls requestFullscreen() upon receiving the message.
Going fullscreen requires coordination with the browser process, so
ordering is preserved by browser IPC message handling.

Daniel​


On Mon, Jul 28, 2014 at 11:56 PM, Anne van Kesteren 
wrote:

> On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth  wrote:
> > I meant a black-box experiment (i.e., no access to browser internal
> state).
> > Put another way, can you describe a sequence of events in which the
> author
> > or the user could observe the difference?  If not, then the question is
> > moot.
>
> Well if both A and B invoke requestFullscreen() that's obviously for
> different elements. The observable difference would be which element
> ends up being fullscreen of course and which call would either fail or
> end up overwriting the other depending on how we decide to deal with
> this.
>
>
> --
> http://annevankesteren.nl/
>

Re: [whatwg] Fullscreen API and out-of-process

[Daniel Cheng]

Caveat: I'm not really familiar with the fullscreen API implementation in
Chrome.

I imagine the synchronous checks would be implemented with a sync IPC from
the requesting renderer to the browser (which implies the browser process
must keep track of the fullscreen enabled flag and whether or not the
fullscreen element stack is empty on a per-frame basis). I'm not sure what
the best approach is to implement step 5 of the requestFullscreen API (
http://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen), but it
seems like we could use the browser process to coordinate the work across
different renderers (where we walk through the documents list). Any
subsequent tasks that need to run in different renderers can probably just
all be posted at the same time.

As for the racing issues... they don't seem out-of-process iframe specific
to me? Perhaps I'm missing something here.

Daniel


On Mon, Jul 28, 2014 at 10:58 AM, Anne van Kesteren 
wrote:

> On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth  wrote:
> > Can you explain what experiment you could run to determine whether (2)
> > happens synchronously or asynchronously?
>
> I'm not sure I understand the question.
>
> Do you mean if you can observe that the tasks in different documents
> might run at the same time? I don't think you could observe that.
>
> The problem I have is addressing the racing issues with this API.
>
>
> --
> http://annevankesteren.nl/
>

Re: [whatwg] The src-N proposal

[Daniel Cheng]

On Mon, Nov 18, 2013 at 12:19 AM, Tab Atkins Jr. wrote:

> On Sun, Nov 17, 2013 at 5:16 AM, Ryosuke Niwa  wrote:
> > Without starting a debate on what semantics or aesthetics mean, syntax
> is a big deal.  A bad syntax can totally kill a feature.
>
> Believe me, I agree; I named my last coding project "Bikeshed", after all.
> ^_^
>
> This is why I find it puzzling that a syntax accepted by the RICG and
> a lot of authors is being shot down by a few implementors.  This is
> why I've been classifying the objections as "personal aesthetic
> concerns" - I don't know how to classify them otherwise.  The proposed
> syntax doesn't seem to offend average authors, who grasp it well
> enough (it's a pretty simple translation from what they already liked
> in ).  It just offends a few of you from WebKit, some of whom
> have been a bit hyperbolic in expressing their dislike.
>
> ~TJ
>

​I think it's worth pointing out that there are some ​Chromium/Blink
developers that don't like the multiple attribute syntax either (for what
it's worth, I am one of them).

Daniel

[whatwg] Default draggable elements

[Daniel Cheng]

Regarding elements that are draggable by default:
The spec says:
> img elements and a elements with an href attribute have their draggable
attribute set to true by default.

I've noticed that in IE and Firefox, an  tag embedding an image
also defaults to draggable. It does not default to draggable in
Blink/WebKit. Should the spec be amended to include this special case?

Blink/WebKit also make input[image] elements default to draggable (no other
browser does this). I'm not really sure why, but can I confirm that this
won't be in the spec? I'd like to remove it from Blink at least.

Daniel

Re: [whatwg] Proposed addition to Drag and Drop API

[Daniel Cheng]

I tested locally and it works for me--if I set a specific element as the
drag image, it gets used instead of the entire draggable element.

Daniel


On Mon, Jul 2, 2012 at 10:06 AM, Alex Bain  wrote:

> I did a bit of reading about what the WhatWG spec says setDragImage should
> do and wanted to ensure I understand what the spec is saying and how Webkit
> is behaving.
>
> Spec:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-datatransfer-setdragimage
>
> The spec says defines "setDragImage" as: setDragImage(element, x, y)
>
> Element argument is defined as: "If the element argument is an img
> element, then set the drag data store bitmap to the element's image (at its
> intrinsic size); otherwise, set the drag data store bitmap to an image
> generated from the given element (the exact mechanism for doing so is not
> currently specified)."
>
> This says, if I'm understanding it correctly, that I can provide any
> element as the first argument and a bitmap image will be generated as a
> drag image. This would allow me to accomplish what I'm trying to do
> (setting a small drag element to represent a larger draggable container).
> However, in my testing, Webkit will not render anything unless the element
> specified is an image.
>
> Am I misunderstanding the spec, or might this be a bug in the
> implementation?
>
> Thanks,
>
> - Alex
>
> On Friday, June 29, 2012 at 4:37 PM, Alex Bain wrote:
>
>  @Ryosuke - I do not have a concrete proposal but would be interested in
> helping to work one out. I had idly considered a content attribute but
> think that specifying an element (perhaps via a function called
> setDragElement()) would be a simple implementation.
>
> @Daniel - I had thought that was possible but in my testing I was not able
> to get it to work. I had tried referencing an existing element as well as
> creating a new element but neither were visible while dragging [in Chrome].
>
> On Friday, June 29, 2012 at 4:30 PM, Daniel Cheng wrote:
>
> Can't you use setDragImage() and pass it the element that holds the post
> title?
>
> Daniel
>
>
> On Fri, Jun 29, 2012 at 4:27 PM, Ryosuke Niwa  wrote:
>
> On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain  wrote:
>
> I would prefer not to visually drag the entire post around (which is what
> happens if I set draggable to true on the post container). My goal is to
> set draggable on a container element and only show a small element when the
> user starts dragging.
>
>
> Ah, that's an interesting use case. Thanks for clarification. Do you have
> a concrete proposal for this? (e.g. adding new content attribute / element).
>
> - Ryosuke
>
>
>
>
>

Re: [whatwg] Proposed addition to Drag and Drop API

[Daniel Cheng]

Can't you use setDragImage() and pass it the element that holds the post
title?

Daniel


On Fri, Jun 29, 2012 at 4:27 PM, Ryosuke Niwa  wrote:

> On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain  wrote:
>
>> I would prefer not to visually drag the entire post around (which is what
>> happens if I set draggable to true on the post container). My goal is to
>> set draggable on a container element and only show a small element when the
>> user starts dragging.
>>
>
> Ah, that's an interesting use case. Thanks for clarification. Do you have
> a concrete proposal for this? (e.g. adding new content attribute / element).
>
> - Ryosuke
>
>

[whatwg] Data store readability in drag/dragend

[Daniel Cheng]

Can we make the drag data store available in read only mode in drag or
dragend? Presumably they are getting fired at the source element that
originally set the data in dragstart, so it's not a security issue.
http://www.onemanmmo.com/index.php?cmd=newsitem&comment=news.1.83.0 is one
person's attempt to work around the current limitations of the system.

Daniel

Re: [whatwg] Changing the type of event.dataTransfer.types

[Daniel Cheng]

We've reverted it back to an Array in WebKit.
Should the "live" requirement remain if it's an Array rather than a
DOMStringList?

Daniel

On Fri, Feb 24, 2012 at 02:11, Anne van Kesteren  wrote:

> On Fri, 24 Feb 2012 02:38:08 +0100, Daniel Cheng 
> wrote:
>
>> For a long time, WebKit returned types as an Array rather than a
>> DOMStringList. I fixed this recently, but arv pointed out that
>> DOMStringList is deprecated in favor of Array:
>> http://dvcs.w3.org/hg/domcore/**raw-file/tip/Overview.html#**
>> interface-domstringlist<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domstringlist>
>>
>> Given that, wouldn't it make sense to change event.dataTransfer.types to
>> be
>> a live Array instead of a live DOMStringList? It's not needed for legacy
>> compatibility with IE, which didn't have .types. It was implemented
>> differently in Gecko and WebKit, so pages ought to be checking for this
>> already with:
>> if (event.dataTransfer.contains) {
>>  ...
>> } else if (event.dataTransfer.indexOf) {
>>  ...
>> }
>> As a result, the burden of such a change to well-behaved web developers
>> should be minimal.
>>
>
> Yes lets do this!
>
> I also filed
>
> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=16102<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16102>
> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=16103<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16103>
>
> to get it removed from Microdata and Indexed DB. The only remaining user
> of DOMStringList is CSSOM (Document.styleSheetSets) to my knowledge and I
> think that can be changed still too (not implemented everywhere yet). If
> that's done DOMStringList can be moved to the historical section of the DOM
> (aka the graveyard).
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] FileList usage

[Daniel Cheng]

FileList is supposed to be live, though it isn't today in WebKit.

Daniel

On Wed, Feb 29, 2012 at 12:14, Boris Zbarsky  wrote:

> On 2/29/12 2:58 PM, Charles Pritchard wrote:
>
>> I'm pretty sure the live ones can't right?
>>>
>>
>> If it's behind a method call, perhaps even a parent attribute, there's
>> opportunity to regenerate, long as there aren't too many sites out there
>> optimizing out the access call.
>>
>
> That a big "as long as".
>
> It's demonstrably false for CSSRuleList and StyleSheetList.
>
> I can't speak to FileList.
>
> -Boris
>

[whatwg] Changing the type of event.dataTransfer.types

[Daniel Cheng]

For a long time, WebKit returned types as an Array rather than a
DOMStringList. I fixed this recently, but arv pointed out that
DOMStringList is deprecated in favor of Array:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domstringlist

Given that, wouldn't it make sense to change event.dataTransfer.types to be
a live Array instead of a live DOMStringList? It's not needed for legacy
compatibility with IE, which didn't have .types. It was implemented
differently in Gecko and WebKit, so pages ought to be checking for this
already with:
if (event.dataTransfer.contains) {
  ...
} else if (event.dataTransfer.indexOf) {
  ...
}
As a result, the burden of such a change to well-behaved web developers
should be minimal.

Daniel

Re: [whatwg] DND: compatibility notes

[Daniel Cheng]

On Fri, Feb 17, 2012 at 01:37, Anne van Kesteren  wrote:

> =Dragging files into the browser=
> * In Opera and FF, you have to preventDefault on the drop event, or the
> browser will correctly open the file *after* handing it to the page. In
> Chrome, simply having a drop listener is enough to prevent it opening the
> file, which is not spec-compliant.
>

I filed a bug for this behavior in WebKit, and one of the responses was the
following:

> Drop a URL on IE6/7/8, the browser navs. Drop a URL in IE6/7/8 on a 
> that cancels the default action of dragenter/dragover, the browser _does
> not_ nav. Same results for a File. The spec is based on IE6; Opera and
> Firefox are out of spec.


My personal opinion is that you should have to cancel the drop event to
prevent the drop's default action, but apparently the IE model does not
agree (I didn't test this personally though). Is the divergence between IE
and the spec intentional?

Daniel

Re: [whatwg] contentEditable and drag and drop cancel

[Daniel Cheng]

The spec doesn't support wildcards today.

Daniel

On Wed, Feb 1, 2012 at 00:17, Ryosuke Niwa  wrote:

> On Wed, Feb 1, 2012 at 12:07 AM, Charles Pritchard wrote:
>
>> The webkitdropzone semantic seems absolutely correct for text entry
>> fields such as input text, contentEditable and textarea.
>> But, the implementation in Chrome does not move the caret, and I don't
>> see an easy way to convey "accept all files".
>>
>> WebKit was recently updated to match the specs:
>> https://bugs.webkit.org/show_**bug.cgi?id=74834
>>
>> The semantics in Chrome M16 were "copy f:image/jpeg" instead of "copy
>> file:image/jpeg".
>>
>> What's the proper way to convey wildcards? "copy file:*/*" ?
>>
>> The behavior of dropzone in M16 has the same behavior as stopPropagation
>> ondragover when the mime type matches.
>> When the mime type does not match, it has the desired behavior of moving
>> the caret. I'd imagine this is a bug, not intentional.
>
>
> In general, our drag & drop support isn't well tested especially inside
> content editable region. I just fixed one of bugs:
> http://trac.webkit.org/changeset/105396.
>
> If you see any weird behavior, please file bugs on bugs.webkit.org. We're
> more than happy to fix those bugs (as long as our time and priority of
> things permits).
>
> - Ryosuke
>
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Daniel Cheng]

On Wed, Nov 16, 2011 at 15:59, Eric U  wrote:

> On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng  wrote:
> > Let's say I drag my pictures directory to a web app uploader. If this
> > uploader passes the DirectoryEntry to my pictures directory to a worker,
> > will it be able to read files I create a long time after the original
> drag?
> > It sounds like the approach being advocated would allow that type of
> attack.
>
> I think it's a bit of an exaggeration to call that an "attack", but
> yes, we'll have to make sure we set expectations appropriately.
>

What do you mean by set expectations?

On Thu, Nov 17, 2011 at 11:12, Kinuko Yasuda  wrote:

> On Fri, Nov 18, 2011 at 3:18 AM, Jonas Sicking  wrote:
> > On Wed, Nov 16, 2011 at 7:09 AM, Kinuko Yasuda 
> wrote:
> >> On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking 
> wrote:
> >>> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard  wrote:
> >>>> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking 
> wrote:
> >>>>>
> >>>>> Adding FileEntry/DirectoryEntry seems confusing since those are
> >>>>> generally writable in the FileSystem API spec, right? Additionally,
> >>>>> DirectoryEntry is asynchronous, which makes enumerating the tree more
> >>>>> painful.
> >>>>>
> >>>>> The way we were planning on exposing this in Gecko is to simply set
> >>>>> File.name to the full relative path to the folder dropped. So in the
> >>>>> example above, if the user dropped the "Photos" folder from the
> >>>>> example above on a page, we'd make .files return a list of 7 Files,
> >>>>> with names like "Photos/trip/1.jpg", "Photos/trip/2.jpg",
> >>>>> "Photos/trip/3.jpg", "Photos/halloween/a.jpg", etc.
> >>>>
> >>>> That requires a full directory traversal in advance to find all of the
> >>>> files, though; the tree could be very large.  For example, a sharded
> >>>> directory tree containing hundreds of thousands of files with
> individual
> >>>> frames of a video isn't unheard of, and there's no need to read it
> all in
> >>>> advance.  Directory trees with tens of thousands of photos, audio
> clips,
> >>>> emails (Maildir), etc. aren't uncommon, either.
> >>>>
> >>>> DirectoryEntry's asynchronous API seems to have the same advantages
> here as
> >>>> they do for regular filesystem access.  It would also set the stage
> for
> >>>> exposing writable directories down the line (eg. drag an input and
> output
> >>>> directory for file processing), after the security issues are figured
> out.
> >>>
> >>> You need to do that anyway to implement the .files attribute, no?
> >>
> >> Yes, but even we provide the attribute today it wouldn't give the best
> >> user experience or could be broken with some likely scenarios.
> >>
> >> If we could think of better option I think we should make it available.
> >
> > I'm not sure I understand what you mean.
> >
> > As long as you support the .files property, you need to traverse all
> > files that are selected before firing the final drop event. Otherwise
> > you risk having to do synchronous IO if someone does access the .files
> > property.
> >
> > Though you could do what another email in this thread suggested and
> > not traverse subdirectories when populating .files. Is that what
> > you're planning to do?
>
> (I think I have confused you, sorry)
>
> We support folders in .files for  but only when
> 'webkitdirectory' is specified, so we do not always do the traversal.
> We do not support folders in .files in dataTransfer either (and no
> plan to do so for now).
>
> > I'm still not convinced that providing an API which provides
> > asynchronous traversal of the files is going to lead to a better user
> > experience. In all scenarios that I can think of, the page which
> > received the drop is going to want to traverse the whole directory
> > tree anyway. For example in order to create a list of files which
> > contain images as to display previews of them. Or to store them in the
> > sandboxed FileSystemAPI or IndexedDB. Or to submit the files using XHR
> > to the server.
> >
> > So by providing references to just the root of directories we are not
> > in fact reducing IO, just shifting it from t

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Daniel Cheng]

On Wed, Nov 16, 2011 at 15:31, Glenn Maynard  wrote:

> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng  wrote:
>
>> I'm trying to better understand the use case for DataTransfer.entries.
>> Using the example you listed in your first post, if I dragged those folders
>> into a browser, I'd expect to see File objects with the following names in
>> DataTransfer.files:
>> trip/1.jpg
>> trip/2.jpg
>> trip/3.jpg
>> halloween/a.jpg
>> halloween/b.jpg
>> tokyo/1.jpg
>> tokyo/2.jpg
>> It seems like with that, a web app could implement a progress meter and
>> handle subdirectories easily while using workers. What does the FileSystem
>> API provide on top of that?
>>
>
> The issue isn't when you have seven files; it's when you have seven
> thousand.  File trees can be very large.  In order to implement the above
> API, you need to traverse the entire tree in advance to discover what files
> exist.  The DirectoryEntry API lets you traverse the directory explicitly,
> without having to read the entire tree into memory first, so you don't
> waste time reading file metadata that you don't care about.
>
> For example, you might drag a SVN working copy into a page, which allows
> viewing logs and other data about the repository.  It might easily contain
> tens of thousands of files, but you rarely need to enumerate all of them in
> advance to do useful things with it.
>
> (If the trees are on a slow medium, like a DVD drive or a high-latency
> network drive, even a much smaller number of files can take a long time.)
>
> Even when you do want to traverse it all, there are many other advantages:
> the traversal can be done asynchronously without blocking the page; the
> page can have a cancel button to abort the operation; the page can show
> other information about what it's doing (eg. number of new files, number of
> unrecognized filenames); the page can allow dragging more directories to be
> queued up for processing without having to wait for the first set to
> complete; and so on.
>

I see. I personally feel it's a little confusing to have two different ways
to read files in DataTransfer, and now we're adding a third.


>
> Also, if a page caches a DirectoryEntry from entries, does that mean it
>> can continuously poll the DirectoryEntry to see if the contents have
>> changed to contain something interesting? That seems undesirable.
>>
>
> Nothing needs to be cached.  The DirectoryEntry just represents the
> directory that was dragged; you don't have to look inside the directory at
> all until the page uses it.
>

Let's say I drag my pictures directory to a web app uploader. If this
uploader passes the DirectoryEntry to my pictures directory to a worker,
will it be able to read files I create a long time after the original drag?
It sounds like the approach being advocated would allow that type of attack.


>
>
> --
> Glenn Maynard
>
>
>
Daniel

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Daniel Cheng]

I'm trying to better understand the use case for DataTransfer.entries.
Using the example you listed in your first post, if I dragged those folders
into a browser, I'd expect to see File objects with the following names in
DataTransfer.files:
trip/1.jpg
trip/2.jpg
trip/3.jpg
halloween/a.jpg
halloween/b.jpg
tokyo/1.jpg
tokyo/2.jpg
It seems like with that, a web app could implement a progress meter and
handle subdirectories easily while using workers. What does the FileSystem
API provide on top of that?

Also, if a page caches a DirectoryEntry from entries, does that mean it can
continuously poll the DirectoryEntry to see if the contents have changed to
contain something interesting? That seems undesirable.

Daniel

On Wed, Nov 16, 2011 at 10:21, Glenn Maynard  wrote:

> On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking  wrote:
>
> > > That requires a full directory traversal in advance to find all of the
> > > files, though; the tree could be very large.
> >
> > You need to do that anyway to implement the .files attribute, no?
> >
>
> .files shouldn't recursively include all files inside directories.  (If you
> actually select tens of thousands of files and drag them, then yes, but in
> most cases when you have that many files, they're split into directories
> and you don't normally drag them individually.)
>
>
> On Wed, Nov 16, 2011 at 9:59 AM, Kinuko Yasuda 
> wrote:
>
> >  The unsandboxed storage and actual data doesn't belong to origin, but
> > the 'origin-specific' concept can be applied to the filesystem
> > namespace.
> >
> > I haven't thought about workers cases deeply yet, but am thinking that
> > we should prohibit access to the dropped folders from the other pages
> > than the one that received the drop event.
>
>
> Access to a file should just be limited by whoever has an Entry object
> pointing at it.  The Entry object is essentially a token granting access to
> its associated file(s).
>
>
>
> > As for the entry URLs I'm planning to make the URLs to the dropped
> entries
> > and the filesystem
> > namespace (that only contains the dropped files) expire when the page
> > goes away, hoping this would largely simplify the lifetime and
> > security issues.
> >
>
> I don't think it's possible to do this correctly, because URLs created with
> toURL have no equivalent to revokeObjectURL.  A long-running page has no
> way to avoid "leaking" these references until the page exits.  Adding a
> revoke method for toURL would essentially turn it into URL.createObjectURL.
>
> Needing to revoke URLs when dealing with worker communication also makes it
> very hard for users to get it right.  For example, suppose a Window sends a
> toURL-generated URL to a Worker.  How do you ensure that the URL is revoked
> after the worker has received it and finished converting it back to an
> Entry?  The Worker might be killed (eg. due to CPU quotas) at any time,
> making avoiding resource leaks very hard.
>
> These are just the usual problems with manual resource management, which
> should be avoided if at all possible.  We already have a mechanism that
> cleanly avoids all of this, with structured clone and File.
>
>  > Off-hand, the main issue that directly affects reading is that most
> > > non-Windows filesystems can store filenames which can't be represented
> > by a
> > > DOMString, such as invalid codepoints (most commonly mismatched
> > encodings).
> >
> > How do they appear in File.name in existing .files approach?
> >
>
> I don't have a Linux browser to check.  I'm guessing it won't inform us
> much here, since that didn't have to worry about general file access.
>
> A naive solution in filesystem approach would be silently ignoring
> > such files (probably bad) or having in-memory path mapping (would be
> > slightly better).  For limited read-only drag-and-drop cases we
> > wouldn't need to think about remapping and the mapping could just go
> > away when the page goes away, so hopefully implementing such mapping
> > wouldn't be that hard.
> >
>
> There are probably some cases that we'll just have to accept will never
> work perfectly, and design with that in mind.
>
> To take a common case, suppose a script does the following, a commonplace
> method for safe file overwriting (relatively; the needed flush operations
> don't exist here):
>
> 1. Create a file with the name filename + ".new".
> 2. Write the new file contents to the file.
> 3. Rename filename + ".new" to filename, overwriting the original file.
>
> This is a useful case: it's real-world--I've done this countless times--and
> it's a case where unrepresentable filenames affects both reading and
> writing, plus the auxiliary operation of renaming.
>
> I suppose the mapping approach could work here.  Associate the mapping with
> the DirectoryEntry containing it, from invalid filenames to generated
> filenames.  Then, if the invalid filename is "X", and the DOMString mapping
> is "MAPPING1", then this would first create the literal

Re: [whatwg] Drag and drop: bugged implementation of setting drag feedback with setDragImage?

[Daniel Cheng]

That's fine. The reason it works that way is inside the dragstart handler,
when you call setDragImage, we merely retain a reference to the element you
passed in. We don't actually create the drag image until after dragstart
processing is finished. As I read it though, setDragImage() is supposed to
snapshot the element at the time the method is called.

Daniel

On Fri, Sep 30, 2011 at 13:13, Rafał Miłecki  wrote:

> W dniu 30 września 2011 19:44 użytkownik Daniel Cheng
>  napisał:
> > Please file a bug for WebKit at https://bugs.webkit.org and attach your
> test
> > case there (I do not see it on your email).
>
> Please take a look at:
> https://bugs.webkit.org/show_bug.cgi?id=69165
>
> I was afraid attachment can be stopped by the mailing list, that's why
> I sent (without success) attachment in the second mail. Now you can
> see test case using Webkit's bugzilla:
> https://bug-69165-attachments.webkit.org/attachment.cgi?id=109335
>
> Seeing the same behavior in Webkit and Gecko made me thinking if this
> is really a bug. Or my misinterpretation of specs. That's why I
> decided to post this e-mail before reporting bug.
>
> P.S.
> Daniel: I hope you don't mind I responded to you *and list*.
>
> --
> Rafał
>

Re: [whatwg] Hashing Passwords Client-side

[Daniel Cheng]

A variation of this idea has been proposed in the past but was largely seen
as undesirable--see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
general, I feel like the same objections are still true of this proposal.

Daniel

On Thu, Jun 16, 2011 at 14:08, Tab Atkins Jr.  wrote:

> On Thu, Jun 16, 2011 at 12:59 PM, Sean Connelly  wrote:
> > I've just joined the mailing list, and this is my first time in such an
> > environment, so I apologize ahead of time if I'm not using the list
> > correctly.
>
> Nope, you did pretty good.  You listed a problem, and then proposed a
> solution to it.  Most people forget to do that first part when they
> start posting.  ^_^
>
>
> > ## Problem Attempting to Solve:
> >
> > Websites commonly need to store login information for users.  Web
> developers
> > may naively store the password in non-secure ways (plain-text, md5 with
> no
> > salt, etc).  It has become common for hacker groups to target websites to
> > get a data-dump of all users/passwords, and using this information, try
> to
> > compromise accounts on other websites.
> >
> > One example below:
> >
> >
> http://arstechnica.com/security/news/2011/06/lulzsec-rampage-continues-62k-e-mails-and-passwords-cia-under-attack.ars
>
> Or, more concretely, you *never* actually need to store the password
> that someone is using.  Like, ever.  You should *always* immediately
> hash the password with a good cryptographic hash, and only store the
> hashed value.  The only thing you should ever need to do with the
> plaintext password is pass it to your hashing function, and then
> immediately forget it.
>
> However, a non-trivial number of servers don't do this, which is the
> source of constant security headaches.
>
>
> > ## Proposed Solution:
> >
> > Add an attribute to  called "hash".  For example:
> > 
> >
> > This will indicate to the browser that it needs to hash the value locally
> > before sending it to the server.  This hash should include a
> site-specific
> > salt, so that the same password typed on two different sites will hash to
> > different values.  I propose the default salt to be the origin as an
> ASCII
> > string (protocol + host + port, ex: "http://example.com:80";), and the
> > default hash to be "none" (in order for backward compatibility).
> >
> > By hashing the password before transmitting to the host, the host is
> never
> > actually aware of the password typed by the user.  The host can treat it
> as
> > a normal password, and store it as it would normally store any other
> > password.  Authentication can still be performed because the host would
> > check to see if the hashes matched.
> >
> > In order to deal with migration correctly, the browser will also need to
> > communicate to the server that it correctly performed the hash.  I
> propose a
> > new header for the browser to send:
> >
> > X-Password-Hash: 1
> >
> > If the browser does not send this header, then the host should expect to
> > receive an unhashed, plain-text password.
> >
> > Each available hash function (sha1, sha2, etc), will have to be
> identified
> > in the spec, along with the format the hash should be transmitted in
> > (lower-case hex dump?).
>
> Personally, I'd prefer the information be transmitted via another
> (browser-synthesized) form input, as it's usually much easier to read
> form inputs than header values.
>
> (Also, X-* headers are an antipattern.  The X- prefix serves
> absolutely no purpose.  This is just a naming issue and irrelevant to
> your proposal; I just wanted to inform you in case you're ever
> directly responsible for naming a header in the future.)
>
> I like your idea for the default salt.  We might be able to hook off
> of slightly better concepts (use the origin directly?) but the idea is
> sound.
>
> For the @hash attribute, we should just specify a single hash for now,
> the strongest we believe we can rely on.  Then we can make it the
> default value, so utilizing this would be as simple as  type=password hash>.  (You don't need a "none" value, since the lack
> of the attribute would indicate that.)  If this becomes inadequate in
> the future, we can just add more values.
>
>
> > ## Benefits:
> >
> > 1. Host never has access to actual password (as long as user has a modern
> > browser)
> > 2. If the host is compromised, hackers may be able to takeover the
> account
> > on the server, but will not be able to take over accounts on different
> > servers even if the user uses the same password (because the hackers will
> > only have access to the hashed password with site-specific salts)
> > 3. Plain-text passwords cannot be sniffed over HTTP
> > 4. Easy for webmasters to upgrade for additional security benefit
>
> For #3, you can still sniff the hashed password over HTTP, and then
> just submit that manually.  But point #2 mitigates the damage that
> would do, unlike the current state of affairs.
>
>
> > ## Disadvantages:
> >
> > 1. Host cannot validate password requirem

Re: [whatwg] Rich Paste & DataTransfer / DataTransferItems API

[Daniel Cheng]

On Mon, Mar 14, 2011 at 20:14, Glenn Maynard  wrote:

> On Mon, Mar 14, 2011 at 10:47 PM, Daniel Cheng 
> wrote:
> > Is there an alternate bitmap format that's likely to be widely supported
> > across different browsers? I picked PNG since if the compression proves
> to
> > be expensive, we can simply try less hard to compress the data (at the
> > extreme end, we don't compress it at all and it basically just becomes a
> > bitmap container).
>
> Yeah, but if the user can't say whether the user wants compressed data
> or not, just tweaking the compression level is always going to be bad
> for one use case (canvas) or the other (uploads).
>
> Using PNG even for uncompressed data does sound better than BMP.
> Alpha channel, 16bpp color, color management, etc. can all still
> apply.
>
> --
> Glenn Maynard
>

Isn't there an image resize API? IMO, that sounds like things that should be
handled by that API.

On Mon, Mar 14, 2011 at 20:15, Jeb Boniakowski  wrote:

> Glenn's point is a good one and the problem isn't whether the bitmap
> will be supported across the browsers, its whether the bitmap will
> make it to the system pasteboard in the first place (assuming its
> being put there from a source other than the browser.  While the
> browser could push pngs or whatever, imagine how frustrating it would
> be to users if you could paste after copying from a browser window but
> not from a random desktop app).
>
> At least on OS X, it looks like applications make sure to make copied
> images available in tiff and pict formats, presumably so every
> drag/paste target doesn't have to support converting from every image
> format (also IIRC tiff and pict are pretty simple 'buffer of pixels w/
> a header' formats, right?)
>
> So the AFAICT possibilities are:
>  - Do what Glenn said and design an async API, which is more
> complicated for the spec, implementors, and users
>  - Cheat.  e.g. monitor the system clipboard in a background thread
> and begin converting anything matching the system's image formats in
> the background/when usage is low, and then only block if you don't
> convert in time.  This is...gross, but would be simple to use.
>
> jeb.
>
> On Mon, Mar 14, 2011 at 11:47 PM, Daniel Cheng 
> wrote:
> > I probably sent it with the wrong from: address.
> >
> > On Mon, Mar 14, 2011 at 19:21, Glenn Maynard  wrote:
> >>
> >> (Was Daniel's reply off-list?)
> >>
> >> On Mon, Mar 14, 2011 at 9:14 PM, Jeb Boniakowski 
> wrote:
> >> > On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng 
> wrote:
> >> >> I'm currently 60-75% complete landing the patches for image paste
> >> >> support in
> >> >> Chrome. I've chosen to expose image/png instead of a raw bitmap
> through
> >> >> event.clipboardData.items in Chrome as a Blob.
> >> >> DataTransferItem::getAsFile()
> >>
> >> That's a good starting point.  I'd suggest that a different entry
> >> point is needed to support this fully.  A couple things that come to
> >> mind:
> >>
> >> PNG compression is expensive; on a larger image it may take 5-10
> >> seconds; more for more aggressive compressors.  This wants an async
> >> API, so compression doesn't block and compression can be threaded.  (A
> >> mechanism that can support Progress Events would make a lot of sense,
> >> too--something for much later, of course, but should at least be kept
> >> in mind, since func(successCb, errorCb) interfaces don't handle that
> >> nicely.)
> >>
> >> The same thing applies to Canvas:
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029492.html
> >>
> >>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030381.html
> >> (Ian's reply)
> >>
> >> Canvas users would also want to be able to load a pasted image without
> >> redundant compression and decompression steps.
> >>
> >> --
> >> Glenn Maynard
> >
> > Is there an alternate bitmap format that's likely to be widely supported
> > across different browsers? I picked PNG since if the compression proves
> to
> > be expensive, we can simply try less hard to compress the data (at the
> > extreme end, we don't compress it at all and it basically just becomes a
> > bitmap container).
> > It would definitely be nice if you didn't need to know the length of the
> > data when creating a Blob.
> > Daniel
>

It's actually fairly trivial to get bitmaps from the system clipboard on
most platforms (I can't speak for Linux because I haven't examined it as
much), so I'm not too worried about that.

Daniel

Re: [whatwg] Rich Paste & DataTransfer / DataTransferItems API

[Daniel Cheng]

I probably sent it with the wrong from: address.

On Mon, Mar 14, 2011 at 19:21, Glenn Maynard  wrote:

> (Was Daniel's reply off-list?)
>
> On Mon, Mar 14, 2011 at 9:14 PM, Jeb Boniakowski  wrote:
> > On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng  wrote:
> >> I'm currently 60-75% complete landing the patches for image paste
> support in
> >> Chrome. I've chosen to expose image/png instead of a raw bitmap through
> >> event.clipboardData.items in Chrome as a Blob.
> DataTransferItem::getAsFile()
>
> That's a good starting point.  I'd suggest that a different entry
> point is needed to support this fully.  A couple things that come to
> mind:
>
> PNG compression is expensive; on a larger image it may take 5-10
> seconds; more for more aggressive compressors.  This wants an async
> API, so compression doesn't block and compression can be threaded.  (A
> mechanism that can support Progress Events would make a lot of sense,
> too--something for much later, of course, but should at least be kept
> in mind, since func(successCb, errorCb) interfaces don't handle that
> nicely.)
>
> The same thing applies to Canvas:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029492.html
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030381.html
> (Ian's reply)
>
> Canvas users would also want to be able to load a pasted image without
> redundant compression and decompression steps.
>
> --
> Glenn Maynard
>

Is there an alternate bitmap format that's likely to be widely supported
across different browsers? I picked PNG since if the compression proves to
be expensive, we can simply try less hard to compress the data (at the
extreme end, we don't compress it at all and it basically just becomes a
bitmap container).

It would definitely be nice if you didn't need to know the length of the
data when creating a Blob.

Daniel

Re: [whatwg] Rich Paste & DataTransfer / DataTransferItems API

[Daniel Cheng]

I'm currently 60-75% complete landing the patches for image paste support in
Chrome. I've chosen to expose image/png instead of a raw bitmap through
event.clipboardData.items in Chrome as a Blob. DataTransferItem::getAsFile()
is currently specced to return a File; in my local changes, it secretly
returns a Blob instead. I think it may make sense to rename it to
getAsBlob() and change the corresponding add() method in DataTransferItems
to take a Blob. I think these basic changes should support the use case you
want if it gets more widely implemented.

Daniel

On Mon, Mar 14, 2011 at 15:39, Jeb Boniakowski  wrote:

> I would like to be able to paste images from the system clipboard into
> web apps.  E.g. an annotated screengrab right into the bug tracker, a
> pic into emails, an image from twitpic into a blog CMS's post screen.
>
> (Apologies if this has been discussed recently and conclusions made.
> I searched the archives and couldn't find anything.  Also, this email
> recapitulates a lot of stuff that will be familiar to participants in
> this list, but I'm hoping that by posting a summary of the state of
> affairs and then hopefully having errors/misconceptions pointed out,
> it will serve as good archive fodder for future people like me.)
>
> This is of course a special case of richer interaction with the system
> clipboard, but I think its a very special case, for two reasons:
>  - The general case of richer paste is fraught with peril: what the is
> your webapp supposed to do with pointers to various system data
> structures?
>  - The second-most common type of data, after text, manipulated on the
> web is images.  They are a huge part of people's interaction with the
> browser.  People move tons of images all over the web all the time,
> and having to bounce off the local filesystem for everything is a
> pain.
>
> Right now, there are effectively two intertwined APIs in the spec that
> relate to being able to paste images:
>  - The Old API, Microsoft style, which includes
> DataTransfer.getData(format)
>  - The New API: DataTransferItems, etc.
>
> -=The Old API=-
>
> With the Old API, the spec reads as if it could be possible to get
> this data, should the browser feel like giving it to you.  There's
> nothing that specifically limits what data the UA can give you, and it
> sounds like you should be able to ask for whatever the UA tells you it
> has: http://dev.w3.org/html5/spec/Overview.html#dom-datatransfer-getdata
> (note: there seems to a small typo in the current Editor's Draft: the
> getData() method only takes 'format', not a second parameter called
> 'data', right?  That's what the summary tables above say.  In either
> case, these should probably agree).
>
> There's a range in what the browsers return for types.  In Safari
> (r80833), having a png on the clipboard shows you:
>  - com.apple.pasteboard.promised-file-url
>  - public.tiff
>  - NSPromiseContentsPboardType
>  - com.apple.webarchive
>  - public.utf8-plain-text
>  - dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
>  - text/uri-list
>  - Apple files promise pasteboard type
>  - application/x-webarchive
>  - dyn.ah62d4rv4gu8y6y4usm1044pxqzb085xyqz1hk64uqm10c6xenv61a3k
>  - dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
>  - WebURLsWithTitlesPboardType
>  -
> dyn.ah62d4rv4gu8yc6durvwwa3xmrvw1gkdusm1044pxqyuha2pxsvw0e55bsmwca7d3sbwu
>  - CorePasteboardFlavorType 0x75726C6E
>  - CorePasteboardFlavorType 0x75726C20
>  - text/plain
>  - public.url-name
>  - NeXT RTFD pasteboard type
>  - public.url
>  - com.apple.flat-rtfd
>  - com.apple.pasteboard.promised-file-content-type
>  - image/tiff
>
> Whereas the Chrome I have (10.0.648.133) shows me:
>  - text/html
>  - text/uri-list
>  - url
>
> Firefox (3.6.15):
>  - text/x-moz-url
>  - text/x-moz-url-data
>  - text/x-moz-url-desc
>  - text/uri-list
>  - text/_moz_htmlcontext
>  - text/_moz_htmlinfo
>  - text/html
>  - text/plain
>
> I don't think this contravenes the spec, except that for all of those
> rich types in Safari, you don't actually get anything when you ask for
> it.  The spec doesn't really mandate anything that you have to do with
> any specific types of data on the clipboard, which especially makes
> sense when considering data that originates outside the browser.
>
> This has one interesting implication though for data that originates
> inside the browser: drag/drop or paste with images loaded from data
> URIs.  Currently, the clipboard behavior of these is interesting but
> varies:
>  - Chrome will return an img tag with the data uri intact, with the
> Base64-encoded data for type "text/html" (preceded by a meta tag
> telling you you're getting html)
>  - Firefox does pretty much the same thing, minus the meta tag
>  - Safari doesn't present a "text/html" type in this case.  However,
> it does provide a "text/plain", which contains *just* the data uri
> itself.
>
> Now, this situation isn't preventing anyone from doing anything, as
> far as I can tell

[whatwg] Rename DataTransferItems for consistency

[Daniel Cheng]

For consistency with other lists of things (such as Files), would it make
sense to rename DataTransferItems to DataTransferItemList? It makes it
easier to distinguish from DataTransferItem as welll.

Daniel

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

Couple of things I noticed after the changes to the DnD spec:
- event.dataTransfer.types no longer mentions "Text" or "URL". Is this
intentional?
- Does the casing of "Text" and "URL" in the return value of
event.dataTransfer.types matter?

Daniel

On Wed, Nov 17, 2010 at 13:05, Charles Pritchard  wrote:

>  On 11/16/2010 4:05 PM, Daniel Cheng wrote:
>
> On Tue, Nov 16, 2010 at 14:48, Charles Pritchard  wrote:
>
>>   When interacting with non-DOM apps or pages, some platforms can't
>>>> easily
>>>> convert arbitrary MIME types to native data transfer types for
>>>> copy/paste or DnD. For this reason, I think the spec should explicitly
>>>> list MIME types for which UAs should handle the conversion to native
>>>> data transfer types. A couple that come to mind: text/plain,
>>>> text/uri-list, text/rtf, application/rtf, text/html, text/xml,
>>>> image/png, and image/svg+xml. UAs can make a best-effort attempt to
>>>> convert the other types, but it won't be guaranteed that they will be
>>>> there for interaction with non-DOM applications.
>>>>
>>> I'm not sure what this means exactly. Could you elaborate?
>>>
>>
>>  I don't think these need to be "converted" by a UA -- the application
>> which
>> receives the data does that conversion on its own.
>>
>> This is a good use case for "promise"-based data callbacks.
>>
>
>  Automatic conversion is already implemented for some types (text, URL,
> and maybe HTML). It's just not explicitly mentioned in the spec. I'm not
> sure how a policy of no conversion would work; the clipboard
> mechanism/encoding varies greatly from platform to platform. With no
> automatic conversion, a page trying to read text from a drop would have to
> first sniff the operating system, choose the appropriate strategy for
> reading text, and then transcode the result to a DOMString.
>
>  Daniel
>
>
> Sorry, I completely misunderstood this one. I thought you were referring to
> operations from the browser to the desktop.
>
> The UA could handle conversion to image/png. It's low-hanging fruit.
>
> Conversion from complex formats into markup is something that should be
> handled by the non-DOM app, not the UA.
>
> Lacking decent markup conversion, a FileList is fine. I don't have to
> "sniff" the operating system,
> I just have to be determined on what mime types I'm going to support.
>
>

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

On Tue, Nov 16, 2010 at 14:48, Charles Pritchard  wrote:
>
>  When interacting with non-DOM apps or pages, some platforms can't easily
>>> convert arbitrary MIME types to native data transfer types for
>>> copy/paste or DnD. For this reason, I think the spec should explicitly
>>> list MIME types for which UAs should handle the conversion to native
>>> data transfer types. A couple that come to mind: text/plain,
>>> text/uri-list, text/rtf, application/rtf, text/html, text/xml,
>>> image/png, and image/svg+xml. UAs can make a best-effort attempt to
>>> convert the other types, but it won't be guaranteed that they will be
>>> there for interaction with non-DOM applications.
>>>
>> I'm not sure what this means exactly. Could you elaborate?
>>
>
> I don't think these need to be "converted" by a UA -- the application which
> receives the data does that conversion on its own.
>
> This list of transfer types reminds me of all the redundancy that can take
> place in a data transfer.
>
> A sufficiently large XML content file may be transferred in ~4 different
> file formats
> for compatibility with the destination.
>
> This is a good use case for "promise"-based data callbacks.


Automatic conversion is already implemented for some types (text, URL, and
maybe HTML). It's just not explicitly mentioned in the spec. I'm not sure
how a policy of no conversion would work; the clipboard mechanism/encoding
varies greatly from platform to platform. With no automatic conversion, a
page trying to read text from a drop would have to first sniff the operating
system, choose the appropriate strategy for reading text, and then transcode
the result to a DOMString.

Daniel

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

>
> On Tue, 9 Mar 2010, Daniel Cheng wrote:
> >
> > I think files have always been a special case and should continue to be
> > handled that way. I don't think there's any platform pasteboard that
> > supports multiple items of one non-file type, so it'd make the most
> > sense to make it a 1:1 mapping from types to data.
>
> Currently the new DataTransferItems API doesn't enforce the limit of one
> "string" item per type. Should it?


What happens if a page were to add multiple string items of "text/plain"?
How would that translate if dragging to a native app? There's also some
implementation concerns here--it'd be harder/require more memory to preserve
multiple strings of the same type when dragging things within a page.
(If/when Blob support is added, the same comments generally apply)

Daniel

Re: [whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

In that case, I'd like to propose a set of MIME types that the spec
explicitly mentions for interoperability with native apps:
- text/plain for compatibility with IE
- text/uri-list for compatibility with IE
- text/html for rich text formatting. One potential usage--a reference site
such as Wikipedia could implement a drag-out handler which automatically
encapsulates the dragged snippet in a "quote" box and links back to the
source.
- application/rtf for rich text data. RTF is called out in particular since
it allows embedded images, which HTML does not. This would allow someone to
drag-and-drop cells and a graph from a spreadsheet into an email.
- image/png for image transfers. Native drag and drop usually involves
bitmaps, so the UA would automatically perform a lossless conversion from
the native platform-dependent bitmap format to a PNG if the page requested
this type. One example usage is uploading a picture of your desktop--simply
hit 'Print Screen', navigate to the image sharing site, and ^V.
- image/svg+xml for vector image transfers. It should be possible to convert
the various vector formats (WMF, PS, PDF) into SVG, but I'm not sure how
valuable doing this would be.

Those 6 types seem to cover a fairly wide variety of use cases without being
too domain-specific. What do people think?

Daniel

On Tue, Oct 26, 2010 at 03:15, Anne van Kesteren  wrote:

> On Thu, 21 Oct 2010 02:20:57 +0200, Daniel Cheng 
> wrote:
>
>> To clarify, I wasn't proposing that pages need to know details of a
>> particular OS. Things like "text/plain", "text/uri-list", "text/html",
>> etc. are automatically mapped by the UA to whatever the appropriate platform
>> idiom is.
>>
>> I just thought it would be useful to also expose things that the UA itself
>> doesn't natively understand--it just gets passed through to the web content.
>>
>
> I was saying that if you get this on one OS but not another you might get
> pages that depend on a particular OS if not coded carefully.
>
>
>
>  However, this led to the above problem with filenames being exposed. This
>> can, to some extent, be mitigated by blacklisting certain types; I'm just
>> wondering if people feel that the additional utility is worth the risk of
>> potentially exposing file paths because of a chatty file manager, or if
>> anyone has any ideas on how to mitigate this risk.
>>
>
> It should probably work with a whitelist.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] Sync/async drag-and-drop data and Blob

[Daniel Cheng]

It's come to my attention that FileReaderSync is only available on worker
threads. Since the general trend seems to be moving towards no synchronous
operations on the main thread, I'd like to propose changing getData() and
setData() to only handle the legacy types 'Text' and 'URL' for IE
compatibility. If you want to handle any other types, you must go through
getDataAsBlob()/setDataAsBlob().

Daniel

On Fri, Oct 29, 2010 at 15:31, Daniel Cheng  wrote:

> I've been thinking about how to extend DataTransfer to support non-text
> types, such as images or RTF. Some use cases that this would enable:
> - Copying and pasting images between Photoshop and a web-based image
> editing app such as http://canvaspaint.org/.
> - Copying a slide with inline pictures from a presentation and pasting it
> into an email without losing any of the formatting.
>
> Since the data might be in text or binary form, I propose adding Blob
> support to DataTransfer. The proposed additions would add the following two
> functions to DataTransfer:
> Blob getDataAsBlob(in DOMString format);
> void setDataAsBlob(in DOMString format, in Blob data);
>
> Callers would use it like this:
> 
> document.addEventListener('paste', function (event) {
>   var imageBlob = event.dataTransfer.getDataAsBlob('image/png');
>   var reader = new FileReaderSync();
>   var newImage = document.appendChild(document.createElement('img'));
>   newImage.src = reader.readAsDataURL(imageBlob);
> });
> document.addEventListener('copy', function (event) {
>   var bb = new BlobBuilder();
>   bb.append(someFunctionThatConvertsAnImageSelectionToAnArrayBuffer());
>   event.dataTransfer.setData('image/png', bb.getBlob());
> });
> 
>
> By using Blob, callers have the freedom to pick a synchronous or
> asynchronous model. For example, to avoid blocking the page, an image
> editing app might choose to read pasted image data asynchronously in a
> callback:
> 
> function onImageLoaded(event) {
>   // Do something with the event.target.result.
> }
> document.addEventListener('paste', function (event) {
>   var imageBlob = event.dataTransfer.getDataAsBlob('image/png');
>   var reader = new FileReader();
>   reader.onload = onImageLoaded;
>   var newImage = document.appendChild(document.createElement('img'));
>   reader.readAsDataURL(imageBlob);
> });
> 
>
> In addition, getData() and setData() could be redefined to be based on the
> two new functions:
> DataTransfer.prototype.getData = function (format) {
>   var reader = new FileReaderSync();
>   var blob = this.getDataAsBlob(format);
>   return reader.readAsText(blob);
> };
> DataTransfer.prototype.setData = function (format, data) {
>   var builder = new BlobBuilder();
>   builder.append(data);
>   this.setDataAsBlob(format, builder.getBlob());
> };
>
> One issue that I'm not clear how to resolve is the issue of Blob.size. In
> general, the UA won't be able to populate Blob.size without reading in all
> the data first... which defeats the point of using Blob to begin with. Since
> people may not read Blob.size very often in the context of copy-and-paste or
> drag-and-drop, maybe it's acceptable to lazily populate Blob.size only if
> people try querying its value? People who want async behavior won't truly
> get it if they query Blob.size, but I don't see another way around the
> problem.
>
> Daniel
>

Re: [whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

To clarify, I wasn't proposing that pages need to know details of a
particular OS. Things like "text/plain", "text/uri-list", "text/html", etc.
are automatically mapped by the UA to whatever the appropriate platform
idiom is.

I just thought it would be useful to also expose things that the UA itself
doesn't natively understand--it just gets passed through to the web content.
However, this led to the above problem with filenames being exposed. This
can, to some extent, be mitigated by blacklisting certain types; I'm just
wondering if people feel that the additional utility is worth the risk of
potentially exposing file paths because of a chatty file manager, or if
anyone has any ideas on how to mitigate this risk.

Daniel

On Tue, Oct 19, 2010 at 02:29, Anne van Kesteren  wrote:

> On Tue, 19 Oct 2010 00:15:27 +0200, Daniel Cheng 
> wrote:
>
>> Sorry, I'm using "properties" as a generic term for different types of
>> data that might be set in a drag. A lot of file managers try to be helpful
>> and
>> populate alternative metadata for a file. Some of this metadata contains
>> file system paths. If the web dragging clipboard mirrors the native
>> dragging clipboard, then the metadata will be visible to web apps. In this
>> example, if you were on Linux with my patch, you could call
>> event.dataTransfer.getData("x-special/gnome-icon-list") while handling a
>> drop and the returned string would contain the file system path.
>>
>
> It seems wrong to expose it in a way native to a particular operating
> system so it seems better to filter it out for now even if that is more
> work. We should keep web platform APIs OS-independent.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

Sorry, I'm using "properties" as a generic term for different types of data
that might be set in a drag. A lot of file managers try to be helpful and
populate alternative metadata for a file. Some of this metadata contains
file system paths. If the web dragging clipboard mirrors the native dragging
clipboard, then the metadata will be visible to web apps. In this example,
if you were on Linux with my patch, you could call
event.dataTransfer.getData("x-special/gnome-icon-list") while handling a
drop and the returned string would contain the file system path.

Daniel

On Mon, Oct 18, 2010 at 14:12, Tab Atkins Jr.  wrote:

> On Mon, Oct 18, 2010 at 1:59 PM, Daniel Cheng  wrote:
> > However, this leads to issues like file system paths being exposed
> through
> > properties like "x-special/gnome-icon-list" or even "text/plain". What is
> > the expected behavior here? Mirroring the native dragging clipboard
> allows
> > for a much richer interaction with the system, but I'm not sure if we
> need
> > to go out of our way to try to scrub all paths from the drag. After all,
> if
> > you're dropping the file on the page, you're already exposing the
> contents
> > of the file, which are probably much more interesting than just the path.
>
> Could you provide some more detail?  I have no idea what you mean by
> "However, this leads to issues like file system paths being exposed
> through properties like "x-special/gnome-icon-list" or even
> "text/plain"."  Those aren't properties, nor do they expose
> file-system paths.
>
> Do you perhaps mean that they expose generally the origin of the file,
> such that you know if you see "x-special/gnome-icon-list" that the
> file is probably coming from wherever gnome stores that kind of file?
>
> ~TJ
>

[whatwg] Exposing filenames in DataTransfer

[Daniel Cheng]

I've been working on better support of arbitrary MIME types in WebKit for
some time, and I had some implementation questions. In the past, UAs seem to
have gone out of their way to make sure full filesystem paths aren't exposed
to the Javascript (e.g. in the file input control). When I did the work for
WebKit, I implemented the web dragging clipboard as a simple reflection of
the native dragging clipboard.

However, this leads to issues like file system paths being exposed through
properties like "x-special/gnome-icon-list" or even "text/plain". What is
the expected behavior here? Mirroring the native dragging clipboard allows
for a much richer interaction with the system, but I'm not sure if we need
to go out of our way to try to scrub all paths from the drag. After all, if
you're dropping the file on the page, you're already exposing the contents
of the file, which are probably much more interesting than just the path.
Thoughts?

Daniel

Re: [whatwg] HTML5 Drag-and-Drop Specification: dragenter

[Daniel Cheng]

You can set types of your choice in dragstart, since your drag source should
know which is which. By design, drop targets can't inspect anything but the
types until the object is actually dropped.

Daniel

On Mon, Aug 16, 2010 at 17:04, Jason Gross

> wrote:

> Is it possible to get more specificity than just the type of the object
> being dragged?  For example, if I have red images and blue images, and a red
> target and a blue target, and I want to be able to drop red images only on
> the red target, and blue images only on the blue target, is there a good way
> to do this, other than globally keep track of which thing is being dragged?
> Thanks.
>
> -Jason
>
>
> On Mon, Aug 16, 2010 at 7:57 PM, Daniel Cheng  wrote:
>
>> I don't think anything in the spec should prevent that. dragenter handlers
>> attached to different drop targets can check event.dataTransfer.types and
>> decide if they want to accept the drag or not.
>>
>> That being said, do any operating systems actually support multiple
>> concurrent drags and drops? WebKit has some built-in assumptions about there
>> being no more than one drag-and-drop operation (per page possibly--I can't
>> test, since I don't have access to a machine with multi-touch capabilities)
>> and I would be surprised if many other applications didn't have this
>> limitation as well.
>>
>> Daniel
>>
>> On Thu, Aug 12, 2010 at 16:26, Jason Gross 
>> 
>> > wrote:
>>
>>> Greetings,
>>> The specification says that the dragenter event is "used to determine
>>> whether or not the drop target is to accept the drop".  Do functions bound
>>> to this event get any information about the object being dragged?  In
>>> particular, is there a good way to have N drop targets, and have each of
>>> them accept only certain draggables?  If not, it seems to me like a good
>>> feature to have, especially as multi-touch applications/devices become more
>>> prevalent.
>>> Thanks.
>>>
>>> Sincerely,
>>> Jason Gross
>>>
>>
>>
>

Re: [whatwg] HTML5 Drag-and-Drop Specification: dragenter

[Daniel Cheng]

I don't think anything in the spec should prevent that. dragenter handlers
attached to different drop targets can check event.dataTransfer.types and
decide if they want to accept the drag or not.

That being said, do any operating systems actually support multiple
concurrent drags and drops? WebKit has some built-in assumptions about there
being no more than one drag-and-drop operation (per page possibly--I can't
test, since I don't have access to a machine with multi-touch capabilities)
and I would be surprised if many other applications didn't have this
limitation as well.

Daniel

On Thu, Aug 12, 2010 at 16:26, Jason Gross

> wrote:

> Greetings,
> The specification says that the dragenter event is "used to determine
> whether or not the drop target is to accept the drop".  Do functions bound
> to this event get any information about the object being dragged?  In
> particular, is there a good way to have N drop targets, and have each of
> them accept only certain draggables?  If not, it seems to me like a good
> feature to have, especially as multi-touch applications/devices become more
> prevalent.
> Thanks.
>
> Sincerely,
> Jason Gross
>

[whatwg] Extend DataTransfer::getData/setData to handle Blobs

[Daniel Cheng]

It's pretty common for there to be non-text data in a drag-and-drop
operation or copy-and-paste operation. DataTransfer doesn't allow for that
currently, since it only sets and returns DOMStrings.

It'd be nice if we could extend setData/getData to allow for Blobs. Some
random thoughts:
1. Add a bool parameter to setData/getData. If false, treat the data as a
DOMString; if true, treat the data as a Blob.
2. Add an encoding parameter to setData/getData. Encoding can be a string
value naming a text encoding like UTF-8 or ISO-8859-1, or it can be the
string value "binary". If encoding names a text encoding, the UA will
transcode the requested data into/from a DOMString. Otherwise, if the
encoding value is "binary", the UA will treat data as a Blob.
3. Create new DataTransfer functions instead of overloading them, e.g.
setDataBlob, getDataBlob.

I'm not sure which one is the preferred approach. It seems like it'd be nice
to have native support for whatever text encodings the browser understands,
but it seems complicated and I'm not sure it's necessary. Thoughts?

Also, if I wanted to go ahead and implement a prototype in WebKit, should I
prefix it with a UA-specific string, e.g. webkitSetDataBlob?

Daniel

Re: [whatwg] More questions about the DnD API

[Daniel Cheng]

On Tue, Mar 30, 2010 at 2:54 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 02:33:07AM -0700, Daniel Cheng wrote:
> >  But what was the rationale for preventing key events while doing
> DnD?
> >
> >I'm not 100% sure, but I'm assume it's so that the process of dragging
> and
> >dropping doesn't trigger unrelated mouse / keyboard listeners.
>
> Unrelated yes, but that also prevents applications from adding DnD
> functionality based on key presses.
>
> >  Why not make the implied drag and/or dragstart explicitely fired
> when
> >  external applications start DnD in the browser? That might make it
> >  simpler and more consistent.
> >
> >Because those events are intended for a source node. It introduces
> several
> >new problems (which node should get the event? how do authors
> differentiate
> >between the two different types of dragstart?) without really solving
> >anything that isn't already handled by other events. If you have drop
> >targets in your page, you don't really care about a drag and drop
> operation
> >in progress unless the item is dragged over your page--at which point
> one
> >can simply use dragenter / dragover / dragleave.
>
> How about registering the drag/dragstart on window.external?
>
> So you're saying that if I start dragging from a document element (say a
> div) and from an external application over the document, in both cases a
> dragenter listener registered on the body element should get fired even
> when the drag is currently over a descendent of the body?
> Same for dragleave when the drag is finished or the drag went out of the
> browser window (to other external apps for example)?
>
> If so, then I can live with this.
>

Yep, as long as event propagation is not stopped.


> --
> Stéphane Epardaud
>

Re: [whatwg] More questions about the DnD API

[Daniel Cheng]

On Tue, Mar 30, 2010 at 1:58 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 01:50:45AM -0700, Daniel Cheng wrote:
> >  I want to do more than most file managers and let users visit
> >  subdirectories by pressing control while over them, so they can
> continue
> >  the drag operation inside the directory (and go deeper potentially).
> >  A separate event makes it much easier to detect the key press.
>
> But what was the rationale for preventing key events while doing DnD?
>

I'm not 100% sure, but I'm assume it's so that the process of dragging and
dropping doesn't trigger unrelated mouse / keyboard listeners.


>
> >  No I mean, when an external application initiates a drag and then
> enters
> >  my browser window/document to look for potential places where it
> could
> >  drop it. I want to detect that and highlight all drop targets in the
> >  page. I would do this in the "drag" or "dragstart" events if this
> was
> >  started in the document, but how to do it when it is started by an
> >  external application?
> >
> >I'd probably use a dragenter listener on the body of the document.
>
> I couldn't get that to work properly with FF 3.6 and gave up after a few
> crashes and hangs (which admitedly are not the spec's fault).


This is probably just an artifact of an incomplete implementation. I don't
think any released browser has implemented 100% of the DnD interfaces yet.
I've also  noticed that some browsers hang if you use alert() during a DnD
event.


>
> Why not make the implied drag and/or dragstart explicitely fired when
> external applications start DnD in the browser? That might make it
> simpler and more consistent.
>

Because those events are intended for a source node. It introduces several
new problems (which node should get the event? how do authors differentiate
between the two different types of dragstart?) without really solving
anything that isn't already handled by other events. If you have drop
targets in your page, you don't really care about a drag and drop operation
in progress unless the item is dragged over your page--at which point one
can simply use dragenter / dragover / dragleave.


> --
> Stéphane Epardaud
>

Re: [whatwg] More questions about the DnD API

[Daniel Cheng]

On Tue, Mar 30, 2010 at 1:39 AM, Stef Epardaud  wrote:

> On Tue, Mar 30, 2010 at 01:31:15AM -0700, Daniel Cheng wrote:
> >  But then it's up to the developer to detect that the keys weren't
> >  pressed before (implement keydown events themselves), which is less
> >  practical.
> >
> >If you're copying the behavior of file managers, isn't it simply a
> matter of
> >setting dropEffect to whatever the current state of the modifier keys
> are?
> >function dragOver(e) {
> >Â Â if (e.ctrlKey) e.dropEffect = 'copy';
> >Â Â else e.dropEffect = 'move';
> >Â Â e.preventDefault();
> >}
> >I'm not sure how having separate keyboard events would help in this
> case,
> >since you can't set dropEffect directly from a keyboard event.
>
> I want to do more than most file managers and let users visit
> subdirectories by pressing control while over them, so they can continue
> the drag operation inside the directory (and go deeper potentially).
>
> A separate event makes it much easier to detect the key press.
>
> >  But if I want to be notified that an external application started a
> drag
> >  in my document, where should I place the listener then? document?
> body
> >  node?
> >
> >If an external application initiates a drag in your DOM page via the
> >appropriate method for your platform, it should be the same as if a
> user
> >initiated it. The dragstart event / drag events should end up getting
> fired
> >at whatever node the application initiated the drag on. Maybe I'm
> >misunderstanding your question though...
>
> No I mean, when an external application initiates a drag and then enters
> my browser window/document to look for potential places where it could
> drop it. I want to detect that and highlight all drop targets in the
> page. I would do this in the "drag" or "dragstart" events if this was
> started in the document, but how to do it when it is started by an
> external application?
>

I'd probably use a dragenter listener on the body of the document.


> --
> Stéphane Epardaud
>

Re: [whatwg] More questions about the DnD API

[Daniel Cheng]

On Tue, Mar 30, 2010 at 12:38 AM, Stef Epardaud  wrote:

> On Mon, Mar 29, 2010 at 02:04:22PM -0700, Daniel Cheng wrote:
> >  I'm still trying to use the DnD for a real-world use, and keep
> hitting
> >  problems. This is the HTML 5 draft at 7.9.4 Drag-and-drop processing
> >  model:
> >  "From this point until the end of the drag-and-drop operation,
> device
> >  input events (e.g. mouse and keyboard events) must be suppressed."
> >
> >DragEvent (via MouseEvent) should expose ctrlKey, altKey, metaKey, and
> >shiftKey properties.
>
> But then it's up to the developer to detect that the keys weren't
> pressed before (implement keydown events themselves), which is less
> practical.
>

If you're copying the behavior of file managers, isn't it simply a matter of
setting dropEffect to whatever the current state of the modifier keys are?

function dragOver(e) {
  if (e.ctrlKey) e.dropEffect = 'copy';
  else e.dropEffect = 'move';
  e.preventDefault();
}

I'm not sure how having separate keyboard events would help in this case,
since you can't set dropEffect directly from a keyboard event.


>
> >dragstart and drag events are fired at the source node, but since
> you're
> >dragging from a non-DOM application, you won't get any. You should
> still be
> >getting dragenter / dragover / dragleave / drop if the item is
> >dragged/dropped over a DOM page though. It works for me in WebKit.
>
> But if I want to be notified that an external application started a drag
> in my document, where should I place the listener then? document? body
> node?
>

If an external application initiates a drag in your DOM page via the
appropriate method for your platform, it should be the same as if a user
initiated it. The dragstart event / drag events should end up getting fired
at whatever node the application initiated the drag on. Maybe I'm
misunderstanding your question though...


> --
> Stéphane Epardaud
>

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

I like the DataTransferItems proposal. I had a few questions, but no one
answered, so I'm going to propose some modifications:

DataTransferItems is a mapping of types to data like DataTransfer.
DataTransfer mirrors DataTransferItems, but DataTransfer.getData() will
throw an error if the data is a blob. Maybe a second getData method that can
provide conversion given a text encoding would be useful?

DataTransfer changes:
DataTransfer.addFile(fileData);

dataTransfer.items = DataTransferItems

DataTransferItems.length
  .getItem(type) = DataTransferItem
  .add(stringData, type)
  .add(blobData)
  .add(dataTransferItem)
  .clear()

DataTransferItem.kind = 'string', 'blob'
  .type = MIME type
  .getTextData(function callback (data)) - throws if binary is true
  .getBlob() - returns Blob

The binary property has been folded into the "kind" property.

When interacting with non-DOM apps or pages, some platforms can't easily
convert arbitrary MIME types to native data transfer types for copy/paste or
DnD. For this reason, I think the spec should explicitly list MIME types for
which UAs should handle the conversion to native data transfer types. A
couple that come to mind: text/plain, text/uri-list, text/rtf,
application/rtf, text/html, text/xml, image/png, and image/svg+xml.
UAs can make a best-effort attempt to convert the other types, but it won't
be guaranteed that they will be there for interaction with non-DOM
applications.

Daniel

On Tue, Mar 9, 2010 at 3:03 PM, Daniel Cheng  wrote:

> On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov  wrote:
>
>> On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng  wrote:
>>
>>> Several questions about the proposal:
>>> How does DataTransferItems interact with the original DataTransfer
>>> object? I'm assuming changes in one should be reflected in the other. If
>>> that's the case, what should happen if I do this:
>>> dataTransfer.items.add(fileData);
>>> dataTransfer.getData(mimeTypeForFile);
>>>
>>
>> Unless there is a specific reason to think different, there is only one
>> set of items backing DataTransfer object - today the files and 'other items'
>> are represented separtely, the proposed items list is simply a merged
>> version of the same. In your example you should be able to getData.
>>
>
> Does that mean getData() can return types besides DOMString?
>
>
>>
>>
>>> How come there's no DataTransferItems.get(type) method?
>>>
>>
>> There can be multiple items of that type (dragging several image files).
>> Would it return another items list? What is the use case for this? Also,
>> some items may have empty type (a file with unknown extension).
>>
>
> I think files have always been a special case and should continue to be
> handled that way. I don't think there's any platform pasteboard that
> supports multiple items of one non-file type, so it'd make the most sense to
> make it a 1:1 mapping from types to data.
>
>
>>
>> DataTransferItem provides richer metadata than is available through the
>>> native drag-and-drop interface on most platforms. When dragging data from a
>>> non-DOM application, how do you extrapolate the metadata to fill in the
>>> type/binary fields?
>>>
>>
>> 'type' can be inferred in many cases from file extension, native clipboard
>> format or other means. It can be done w/o content sniffing and disk IO.
>>
>
> Should there be some sort of standard list of mappings that all UAs should
> support wherever possible? What happens if the UA doesn't have a mapping for
> a type?
>
>
>>
>> I understand 'binary' as indicator of whether or not the item can be read
>> as a text string. I'm not sure why item.kind == "string" is not the same. If
>> the intent is to also cover some files that can be read as string and as
>> Blob, then it might be buggy because the only way to establish if the file
>> can be converted into JS string is to actually read the bytes and try to
>> convert to Unicode. There can be invalid character sequences or the encoding
>> info may be missing.
>>
>> Perhaps we should remove 'binary' and assume that items that item.kind ==
>> "string" can use getTextData(callback) to pull the string.
>>
>> On a separate note, I think items.add(dataTransferItem) is not useful w/o
>> a way to create a new DataTransferItem separately from the DataTransferItems
>> list.
>>
>>
>>>
>>> Daniel
>>>
>>>
>>> On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson

Re: [whatwg] More questions about the DnD API

[Daniel Cheng]

On Sun, Mar 28, 2010 at 1:29 PM, Stef Epardaud  wrote:

> Hello,
>
> I didn't get any reaction to my previous email unfortunately since I
> think I brought up some valid points, but in any case I have some more
> feedback, so I keep sending :)
>
> I'm still trying to use the DnD for a real-world use, and keep hitting
> problems. This is the HTML 5 draft at 7.9.4 Drag-and-drop processing
> model:
>
> "From this point until the end of the drag-and-drop operation, device
> input events (e.g. mouse and keyboard events) must be suppressed."
>
> This looks crazy to me. First Mozilla doesn't limit this since I was
> able to get a keypress event while dragging a node. I use this to change
> the behaviour of the drag operation with control/meta/alt keys while
> dragging, the same way file managers do it (at least Gnome Nautilus) and
> lots of other applications (Open Office for example). We need to be able
> to access key events while dragging. There might be a good rationale for
> this limitation stated in the spec, but based on evidence of how DnD is
> used in other applications perhaps it should be reviewed?
>

DragEvent (via MouseEvent) should expose ctrlKey, altKey, metaKey, and
shiftKey properties.


>
> Personally I also use the key events while dragging to allow the user to
> open folders in order to continue the drag operations inside, instead of
> requiring them to drop the file in the folder, then open the folder and
> drag it again to a subfolder.
>
> I also have a question regarding DnD started in an external application:
> since we get no dragstarted or drag events, how can we detect that
> something wants to be dragged in the window? I want to highlight every
> responsive drop points so the user can know which elements are valid
> drop targets, but failed to get any meaningful interaction with
> dragentered or dragover on the document, or body elements. Surely that's
> a mistake from my part, but since I expect that it's going to be asked a
> lot (when we don't get drag or dragstart events), perhaps it should be
> mentioned in the spec?
>

dragstart and drag events are fired at the source node, but since you're
dragging from a non-DOM application, you won't get any. You should still be
getting dragenter / dragover / dragleave / drop if the item is
dragged/dropped over a DOM page though. It works for me in WebKit.


>
> Thanks for your help.
> --
> Stéphane Epardaud
>

Of course, I have a question of my own. In
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#effectAllowed-initialization,
is it intentional that any drag event can change the value of effectAllowed
for the next event? Does it make sense to making this property settable only
during dragstart / drag?

Daniel

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov  wrote:

> On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng  wrote:
>
>> Several questions about the proposal:
>> How does DataTransferItems interact with the original DataTransfer object?
>> I'm assuming changes in one should be reflected in the other. If that's the
>> case, what should happen if I do this:
>> dataTransfer.items.add(fileData);
>> dataTransfer.getData(mimeTypeForFile);
>>
>
> Unless there is a specific reason to think different, there is only one set
> of items backing DataTransfer object - today the files and 'other items' are
> represented separtely, the proposed items list is simply a merged version of
> the same. In your example you should be able to getData.
>

Does that mean getData() can return types besides DOMString?


>
>
>> How come there's no DataTransferItems.get(type) method?
>>
>
> There can be multiple items of that type (dragging several image files).
> Would it return another items list? What is the use case for this? Also,
> some items may have empty type (a file with unknown extension).
>

I think files have always been a special case and should continue to be
handled that way. I don't think there's any platform pasteboard that
supports multiple items of one non-file type, so it'd make the most sense to
make it a 1:1 mapping from types to data.


>
> DataTransferItem provides richer metadata than is available through the
>> native drag-and-drop interface on most platforms. When dragging data from a
>> non-DOM application, how do you extrapolate the metadata to fill in the
>> type/binary fields?
>>
>
> 'type' can be inferred in many cases from file extension, native clipboard
> format or other means. It can be done w/o content sniffing and disk IO.
>

Should there be some sort of standard list of mappings that all UAs should
support wherever possible? What happens if the UA doesn't have a mapping for
a type?


>
> I understand 'binary' as indicator of whether or not the item can be read
> as a text string. I'm not sure why item.kind == "string" is not the same. If
> the intent is to also cover some files that can be read as string and as
> Blob, then it might be buggy because the only way to establish if the file
> can be converted into JS string is to actually read the bytes and try to
> convert to Unicode. There can be invalid character sequences or the encoding
> info may be missing.
>
> Perhaps we should remove 'binary' and assume that items that item.kind ==
> "string" can use getTextData(callback) to pull the string.
>
> On a separate note, I think items.add(dataTransferItem) is not useful w/o a
> way to create a new DataTransferItem separately from the DataTransferItems
> list.
>
>
>>
>> Daniel
>>
>>
>> On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson  wrote:
>>
>>> On Thu, 4 Feb 2010, Ian Hickson wrote:
>>> > On Sat, 23 Jan 2010, Eduard Pascual wrote:
>>> > >
>>> > > Would it be possible to provide a list of "drag items" (to call them
>>> > > somehow) instead of, or in addition to, the current info provided by
>>> > > the DataTransfer object?
>>> >
>>> > That's a pretty good idea. I think we should probably do this when we
>>> > add more types to the DataTransfer object.
>>>
>>> Some engineers at Google discussed this a bit and came up with the
>>> following proposal:
>>>
>>>   dataTransfer.items = DataTransferItems
>>>
>>>DataTransferItems.length
>>> .getItem(n) = DataTransferItem
>>> .add(stringData, type)
>>> .add(blobData)
>>> .add(fileData)
>>> .add(dataTransferItem)
>>> .clear()
>>>
>>>DataTransferItem.kind = 'string', 'file', 'blob', ...
>>>.type = MIME type
>>>.binary = boolean
>>>.getTextData(function callback (data)) - throws if
>>> binary is true
>>>.getBlob() - returns File or Blob
>>>
>>> When we add promises later, this can easily be extended to support that
>>> as
>>> well (basically, just by adding a new add() method for the promise case).
>>>
>>> I've put this into the comment in the spec, but haven't specced it. If
>>> any
>>> browser vendors want to try implementing this or something like it, any
>>> reports of implementation experience would be very useful. Please prefix
>>> the "items" attribute with some unique string like "webkitItems" or
>>> "geckoItems" so that it doesn't clash with the spec when we do add
>>> something like this!
>>>
>>> Cheers,
>>> --
>>> Ian Hickson   U+1047E)\._.,--,'``.fL
>>> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
>>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>>
>>
>>
>

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

Several questions about the proposal:
How does DataTransferItems interact with the original DataTransfer object?
I'm assuming changes in one should be reflected in the other. If that's the
case, what should happen if I do this:
dataTransfer.items.add(fileData);
dataTransfer.getData(mimeTypeForFile);

How come there's no DataTransferItems.get(type) method?

DataTransferItem provides richer metadata than is available through the
native drag-and-drop interface on most platforms. When dragging data from a
non-DOM application, how do you extrapolate the metadata to fill in the
type/binary fields?

Daniel

On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson  wrote:

> On Thu, 4 Feb 2010, Ian Hickson wrote:
> > On Sat, 23 Jan 2010, Eduard Pascual wrote:
> > >
> > > Would it be possible to provide a list of "drag items" (to call them
> > > somehow) instead of, or in addition to, the current info provided by
> > > the DataTransfer object?
> >
> > That's a pretty good idea. I think we should probably do this when we
> > add more types to the DataTransfer object.
>
> Some engineers at Google discussed this a bit and came up with the
> following proposal:
>
>   dataTransfer.items = DataTransferItems
>
>DataTransferItems.length
> .getItem(n) = DataTransferItem
> .add(stringData, type)
> .add(blobData)
> .add(fileData)
> .add(dataTransferItem)
> .clear()
>
>DataTransferItem.kind = 'string', 'file', 'blob', ...
>.type = MIME type
>.binary = boolean
>.getTextData(function callback (data)) - throws if
> binary is true
>.getBlob() - returns File or Blob
>
> When we add promises later, this can easily be extended to support that as
> well (basically, just by adding a new add() method for the promise case).
>
> I've put this into the comment in the spec, but haven't specced it. If any
> browser vendors want to try implementing this or something like it, any
> reports of implementation experience would be very useful. Please prefix
> the "items" attribute with some unique string like "webkitItems" or
> "geckoItems" so that it doesn't clash with the spec when we do add
> something like this!
>
> Cheers,
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson  wrote:

> On Thu, 4 Feb 2010, Daniel Cheng wrote:
> > >
> > > Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL",
> > > but case-insensitively (at least for Text, I didn't test URL). Chrome
> > > is case-insensitive for everything.
> > >
> > > Tough call. I guess we'll go with just converting everything to
> > > lowercase, so that it's case-insensitive.
> > >
> > > BTW I noticed Chrome includes "Text" and "URL" in the .types list.
> > > That's incorrect according to the spec.
> >
> > If event.dataTransfer converts everything to lowercase, that means there
> > are native formats that will always be impossible to access.
>
> The spec requires that the UA lowercase all the native types as well (and
> that they be converted to MIME types).
>
> Could you elaborate on which types would be a problem, and on what
> platforms?
>

Forcing UA to lowercase all formats has a high implementation cost. Most
DataTransfer implementations now can directly interact with the native
system data object, whatever form that takes. With this change, the UA has
to enumerate (with possible string conversions involved, depending on the
platform) and lower case all formats currently in the drag and
drop/clipboard operation with every call to getData()/setData()/clearData().
Furthermore, what happens if there are collisions after lowercasing?

Also, suppose some Windows app XYZ uses the data format "My Awesome
Clipboard Format". If a page wants to set drag and drop (or clipboard data;
presumably, the interfaces to transfer data are going to remain somewhat
similar), it will be unable to set data in the correct format unless the UA
happens to internally map a MIME type to that data format. Some common MIME
types should definitely be mapped to native data formats, but the interface
shouldn't prevent someone from interfacing with any arbitrary app they want.


>
>
> > Since "text" and "url" are already special, maybe case should only be
> > ignored for those two. All other formats, even if they are actually MIME
> > type strings, should be handled in a case-sensitive manner.
>
> In your previous e-mail, you were arguing they should be
> case-insensitive... I think your earlier arguments are more persuasive.
> The MIME type specs do say they're case-insensitive.
>

True, but I think the problems with making all strings lowercase outweigh
the benefits.


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Drag-and-drop feedback

[Daniel Cheng]

>
> Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but
> case-insensitively (at least for Text, I didn't test URL). Chrome is
> case-insensitive for everything.
>
> Tough call. I guess we'll go with just converting everything to lowercase,
> so that it's case-insensitive.
>
> BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's
> incorrect according to the spec.


If event.dataTransfer converts everything to lowercase, that means there are
native formats that will always be impossible to access. Since "text" and
"url" are already special, maybe case should only be ignored for those two.
All other formats, even if they are actually MIME type strings, should be
handled in a case-sensitive manner.

Daniel

[whatwg] event.dataTransfer formats

[Daniel Cheng]

>
> Formats are generally given by MIME types, with some values special-cased
> for legacy reasons. For the purposes of this API, however, the format
> strings are opaque, case-sensitive, strings, and the empty string is a valid
> format string.


RFC 2616 has this to say about MIME types:

> The type, subtype, and parameter attribute names are case-insensitive.


IE also ignores case for format strings:

> 

  window.clipboardData.setData('Text', 'FAILURE');

  window.clipboardData.setData('tEXT', 'SUCCESS');

  alert(window.clipboardData.getData('Text'));



results in an alert saying 'SUCCESS'.

Given that, would it make sense to change the spec to make format strings
case-insensitive?

Daniel

Re: [whatwg] HTML5 cut/copy

[Daniel Cheng]

Two more questions about implementation details:

Cut/copy:
Does it make sense to fire a drag event at all? The spec says that drag
events should be fired at the source node every 350ms (presumably to allow
the source node to cancel a drag after it started), but a cut/copy takes
place "instantaneously". If drag events should be fired during cut/copy,
should the clipboard be restored to its original state if the drag event is
cancelled? It would make sense, but might make implementations more
complicated.

Paste:
It seems like there is no time a dragleave event would ever fire. A paste
essentially goes through the drag and drop loop once; the only possible
transition is for the current target element to go from null to non-null.

Daniel

On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson  wrote:

> On Tue, 12 Jan 2010, Daniel Cheng wrote:
> >
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard
> >
> > The current spec says that drop events should be fired while handling
> > copy/cut operations. Is this intended? The clipboard is not a DOM
> > element; it seems like it'd make sense only to fire the drop event for
> > pastes.
>
> Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

[whatwg] HTML5 cut/copy

[Daniel Cheng]

http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard

The current spec says that drop events should be fired while handling
copy/cut operations. Is this intended? The clipboard is not a DOM element;
it seems like it'd make sense only to fire the drop event for pastes.

Daniel