W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] contentEditable and drag and drop cancel

From: Daniel Cheng <dcheng@chromium.org>
Date: Wed, 1 Feb 2012 16:44:07 -0800
Message-ID: <CAF3XrKrBxKXHbGsyCJsofujkiUf1on8A0w0i6vNV_5exZgRgMg@mail.gmail.com>
The spec doesn't support wildcards today.

Daniel

On Wed, Feb 1, 2012 at 00:17, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Wed, Feb 1, 2012 at 12:07 AM, Charles Pritchard <chuck at jumis.com>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<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
>
>
Received on Wednesday, 1 February 2012 16:44:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC