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

[whatwg] contentEditable and drag and drop cancel

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Wed, 1 Feb 2012 00:17:31 -0800
Message-ID: <CABNRm60Gt3S0q3C_NgJKZpiVbqUgeBRuzSOXcdss0C5yub0HaQ@mail.gmail.com>
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 00:17:31 UTC

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