Align drag feedback for links with draggable="true" to Safari.

Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
Committed: https://crrev.com/223360c3b8a6f3a13eb5759bd38edb87bbdb4c01
Cr-Commit-Position: refs/heads/master@{#432435}

[pwnall, 2016-10-21 23:33:04]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 23:33:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-22 03:46:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-22 03:46:18]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pwnall, 2016-10-25 00:32:57]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[pwnall, 2016-10-25 00:33:12]

Patchset #1 (id:1) has been deleted

[commit-bot: I haz the power, 2016-10-25 00:33:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-25 00:40:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-25 00:40:28]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pwnall, 2016-10-25 22:32:54]

Description was changed from

==========
WiP: Fix drag and drop behavior for links with draggable="true".

BUG=74302
==========

to

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

[pwnall, 2016-10-25 22:55:36]

Description was changed from

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

to

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
TEST=LayoutTest for drag data store, manual testing for feedback image
==========

[pwnall, 2016-10-25 22:55:58]

pwnall@chromium.org changed reviewers:
+ dcheng@chromium.org

[pwnall, 2016-10-25 22:55:59]

PTAL?

[dcheng, 2016-10-27 06:37:54]

Two thoughts:

1) Is it possible to test the different drag images by writing individual test
cases and using dumpDragImage()?

2) I wonder if we can get the logic by determining if the draggable node is a
link element rather than DragSourceActionLink? That might allow us to dedupe the
logic. It'll look different from the other blocks... but that's OK, I think?

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html
(right):

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:32:
Please attempt to drag the into the "Drop Here" rectangle. No matter whether
drag the what? =)

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:33:
the attempt was successful or not, click into the "End Test" zone.
Why do we need the "End Test" zone?

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:151:
}, 16);
What's the reason for the 16 ms delay?

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:888: if (state.m_dragType
== DragSourceActionDHTML) {
Is this leftover from an earlier CL?

[pwnall, 2016-10-29 00:12:47]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-29 00:13:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-29 00:22:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-29 00:22:27]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[pwnall, 2016-10-29 00:22:45]

Description was changed from

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
TEST=LayoutTest for drag data store, manual testing for feedback image
==========

to

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

[pwnall, 2016-10-29 00:24:24]

dcheng@: Thank you so much for mentioning dumpDragImage()! It will be a life
saver for all my bug fixes that involve the drag feedback image!

This CL doesn't pass presubmit because of a logistical issue*, but can you
please take another look and see if I understood your comments correctly?

* I need to check in -expected.txt files, otherwise the test framework fails the
tests. I think that's because I produce both text and image expectations. I'll
figure this out separately.

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html
(right):

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:32:
Please attempt to drag the into the "Drop Here" rectangle. No matter whether
On 2016/10/27 06:37:53, dcheng wrote:
> drag the what? =)

Done.
Oops, thanks!

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:33:
the attempt was successful or not, click into the "End Test" zone.
On 2016/10/27 06:37:53, dcheng wrote:
> Why do we need the "End Test" zone?

Done.
It is definitely not necessary now that each test gets its own file.

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/drag-and-drop-draggable-link.html:151:
}, 16);
On 2016/10/27 06:37:53, dcheng wrote:
> What's the reason for the 16 ms delay?

Done.
This block got removed together with the "End test" box.

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:888: if (state.m_dragType
== DragSourceActionDHTML) {
On 2016/10/27 06:37:54, dcheng wrote:
> Is this leftover from an earlier CL?

Done.
It was a previous host for the block of code that I moved from
MouseEventManager.cpp. Thanks for catching it!

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:37: #include
"core/dom/DocumentUserGestureToken.h"
This is from a rebase. Sorry, I forgot to upload the rebase separately :(

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:247: UserGestureIndicator
gesture(DocumentUserGestureToken::create(
This is from a rebase. Sorry, I forgot to upload the rebase separately :(

[dcheng, 2016-10-31 22:31:35]

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/dnd/link-dragging-draggable-div-with-dragged-link.html
(right):

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/dnd/link-dragging-draggable-div-with-dragged-link.html:26:
return runLinkDraggingTest(t, {
Nit: it's useful to document the expected result here. For example, maybe the
test could assert what event.target is (for example, from this test, I'm not
100% sure if we're dragging just the <a> element or the <div> as well.

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:914: if
(isHTMLAnchorElement(*node) && toHTMLAnchorElement(node)->isLiveLink() &&
I was thinking we could make this a top-level if () with no else--it's default
behavior we want as long as the dragged node is a link, right? Or do we not want
this behavior if the link being dragged only contains an image? (I don't quite
remember how this case resolves itself)

[pwnall, 2016-11-01 08:43:01]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-01 08:43:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-01 10:03:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-01 10:03:47]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[pwnall, 2016-11-03 04:43:11]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-03 04:43:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-03 06:09:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-03 06:09:02]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[pwnall, 2016-11-03 09:25:48]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-03 09:26:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-03 09:33:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-03 09:33:16]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[pwnall, 2016-11-03 15:35:57]

Patchset #7 (id:140001) has been deleted

[pwnall, 2016-11-04 23:03:07]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-04 23:04:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pwnall, 2016-11-04 23:08:29]

dcheng@: Thank you very much for the feedback, and sorry it took me so long to
turn this CL around! PTAL?

The final tests and baselines are pending the conclusion of the discussion in
https://groups.google.com/a/chromium.org/d/topic/blink-dev/TnyFtz9-EWg/discus...
and http://crrev.com/2477783002, but perhaps we can agree on everything else?

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/dnd/link-dragging-draggable-div-with-dragged-link.html
(right):

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/dnd/link-dragging-draggable-div-with-dragged-link.html:26:
return runLinkDraggingTest(t, {
On 2016/10/31 22:31:34, dcheng wrote:
> Nit: it's useful to document the expected result here. For example, maybe the
> test could assert what event.target is (for example, from this test, I'm not
> 100% sure if we're dragging just the <a> element or the <div> as well.

Done.
Good point! All the tests drag the element with the class "draggable", so I
added an assertion to make sure that the dragged element has the class
"draggable".

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/DragController.cpp:914: if
(isHTMLAnchorElement(*node) && toHTMLAnchorElement(node)->isLiveLink() &&
On 2016/10/31 22:31:35, dcheng wrote:
> I was thinking we could make this a top-level if () with no else--it's default
> behavior we want as long as the dragged node is a link, right? Or do we not
want
> this behavior if the link being dragged only contains an image? (I don't quite
> remember how this case resolves itself)

Done.
I'll learn about this more as I work through the feedback bugs and the image
bugs :D

[commit-bot: I haz the power, 2016-11-04 23:14:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-04 23:14:20]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[dcheng, 2016-11-07 22:16:55]

LGTM with nit addressed.

https://codereview.chromium.org/2441023003/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/DragController.cpp:924: // The layoutObject
has disappeared, this can happen if the onStartDrag
Nit: usually, the error case is ordered first with an early return.

[pwnall, 2016-11-07 22:46:10]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-07 22:46:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-07 22:56:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-07 22:56:17]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[pwnall, 2016-11-07 23:21:16]

Thank you very much for the review!

I'll land this after we figure out testharness.js usage in pixel tests.

https://codereview.chromium.org/2441023003/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/DragController.cpp (right):

https://codereview.chromium.org/2441023003/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/DragController.cpp:924: // The layoutObject
has disappeared, this can happen if the onStartDrag
On 2016/11/07 22:16:55, dcheng wrote:
> Nit: usually, the error case is ordered first with an early return.

Done.

[pwnall, 2016-11-11 23:59:05]

The CQ bit was checked by pwnall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-11 23:59:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-12 01:51:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-12 01:51:40]

Dry run: This issue passed the CQ dry run.

[pwnall, 2016-11-16 01:53:02]

The CQ bit was checked by pwnall@chromium.org

[pwnall, 2016-11-16 01:53:02]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/2441023003/#ps220001
(title: "Rebased, added dependency on CL that fixes testing logistical issue.")

[commit-bot: I haz the power, 2016-11-16 01:53:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-16 02:55:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-16 02:55:11]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pwnall, 2016-11-16 08:16:59]

The CQ bit was checked by pwnall@chromium.org

[commit-bot: I haz the power, 2016-11-16 08:17:18]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-16 08:48:12]

Description was changed from

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

to

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

[commit-bot: I haz the power, 2016-11-16 08:48:13]

Committed patchset #10 (id:220001)

[commit-bot: I haz the power, 2016-11-16 08:50:04]

Description was changed from

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302
==========

to

==========
Align drag feedback for links with draggable="true" to Safari.

On top of the W3C Drag and Drop specification [1, 2], we have special
handling for images and links. When our specialized handling for links
triggers, we generate a specialized drag feedback that includes the
link's text (title) and the URL. For better or for worse, we always
triggerred the specialized behavior for link elements, even when the
elements opt into the W3C Drag and Drop specification using the
draggable="true" attribute. We inherited this behavior from Safari via
WebKit.

At some point, Safari updated its behavior and does not trigger its
specialized feedback for links that have draggable="true". These links
have their drag feedback generated based on their elements' renderings,
and the corresponding drag data store is not pre-populated with link
data.

This CL attempts to get the best from both worlds. Links that have
draggable="true" don't get the specialized drag feedback, so their
feedback matches the element rendering. However, we do pre-populate
their data store according to our specialized behavior. This goes beyond
the spec, which only requires a text/uri-list item. We also add
text/html and text/plain data items.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html

BUG=74302

Committed: https://crrev.com/223360c3b8a6f3a13eb5759bd38edb87bbdb4c01
Cr-Commit-Position: refs/heads/master@{#432435}
==========

[commit-bot: I haz the power, 2016-11-16 08:50:05]

Patchset 10 (id:??) landed as
https://crrev.com/223360c3b8a6f3a13eb5759bd38edb87bbdb4c01
Cr-Commit-Position: refs/heads/master@{#432435}