Selecting with shift+drag results in unexpected drag-n-drop

Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
Committed: https://crrev.com/40285d7edd6ab066b3a9c8756416ea7395b2eb55
Cr-Commit-Position: refs/heads/master@{#403315}

[not to use - tonikitoo, 2016-06-07 18:10:06]

tonikitoo@chromium.org changed reviewers:
+ tonikitoo@chromium.org

[not to use - tonikitoo, 2016-06-07 18:10:07]

PTAL

[not to use - tonikitoo, 2016-06-07 18:12:46]

tonikitoo@chromium.org changed reviewers:
+ rbyers@chromium.org, yosin@chromium.org

[not to use - tonikitoo, 2016-06-07 18:12:47]

yosin@chromium.org, rbyers@chromium.org: PTAL.

[tonikitoo, 2016-06-07 19:31:50]

Ok, debug runs seem to be failing at

11:04:50.384 52505 worker/2
virtual/trustedeventsdefaultaction/fast/events/touch/gesture/gesture-tap-mouse-events.html
output stderr lines:
11:04:50.384 52505  
[53737:1287:0607/110432:88191071088427:FATAL:SelectionController.cpp(640)] Check
failed: event.event().clickCount() <= 1 (20 vs. 1)
11:04:50.384 52505   0   libbase.dylib                       0x000000011af1daee
_ZN4base5debug10StackTraceC2Ev + 30
11:04:50.384 52505   1   libbase.dylib                       0x000000011af1db55
_ZN4base5debug10StackTraceC1Ev + 21
11:04:50.384 52505   2   libbase.dylib                       0x000000011afa2690
_ZN7logging10LogMessageD2Ev + 80
11:04:50.384 52505   3   libbase.dylib                       0x000000011afa0245
_ZN7logging10LogMessageD1Ev + 21
11:04:50.384 52505   4   libblink_core.dylib                 0x00000001267de8af
_ZN5blink20isExtendingSelectionERKNS_23EventWithHitTestResultsINS_18PlatformMouseEventEEE
+ 191
11:04:50.384 52505   5   libblink_core.dylib                 0x00000001267de195
_ZN5blink19SelectionController32handleMousePressEventSingleClickERKNS_23EventWithHitTestResultsINS_18PlatformMouseEventEEE
+ 389
11:04:50.384 52505   6   libblink_core.dylib                 0x00000001267e0361
_ZN5blink19SelectionController32handleMousePressEventTripleClickERKNS_23EventWithHit
(..)

I imagine win_dbg and linux_dbg will show similar failures. Fixing..

[tonikitoo, 2016-06-07 19:39:10]

Description was changed from

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
==========

to

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
==========

[tonikitoo, 2016-06-07 19:39:10]

tonikitoo@igalia.com changed reviewers:
- tonikitoo@chromium.org

[yosin_UTC9, 2016-06-08 01:37:22]

C++ changes seems good once click count issue is resolved.

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:1:
<!DOCTYPE html>
Could you use w3c test harness to avoid to have expected text?

Here is an example:
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/editing/s...

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/editing/SelectionController.cpp (right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/editing/SelectionController.cpp:641: 
nit: no need to have an extra blank line here.

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/editing/SelectionController.h (right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/editing/SelectionController.h:93: 
nit: no need to have an extra blank line here.

[yosin_UTC9, 2016-06-23 07:23:58]

ping...

[tonikitoo, 2016-06-24 16:01:20]

On 2016/06/23 07:23:58, Yosi_UTC9 wrote:
> ping...

Yosi, thanks for reviewing. I have the changes made, but can not run it locally
due to an assert hit on content_shell:

out/Default/content_shell --run-layout-test --no-sandbox
third_party/WebKit/LayoutTests/fast/events
[10981:10981:0624/115748:136792026356:FATAL:fontconfig_util_linux.cc(77)] Check
failed: FcConfigSetCurrent(FcConfigCreate()). 
#0 0x0000033aa49e base::debug::StackTrace::StackTrace()
#1 0x0000033bb04b logging::LogMessage::~LogMessage()
#2 0x0000032a2af7 gfx::SetUpFontconfig()
#3 0x00000337c373 content::BlinkTestPlatformInitialize()
#4 0x00000336a870 content::ShellMainDelegate::BasicStartupComplete()
#5 0x000002dfe7b3 content::ContentMainRunnerImpl::Initialize()
#6 0x000002dfd9aa content::ContentMain()
#7 0x000000440ebb main
#8 0x7f64f3e14580 __libc_start_main
#9 0x000000440db1 <unknown>
Aborted (core dumped)


Does that ring a bell?

[tonikitoo, 2016-06-24 18:39:20]

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:1:
<!DOCTYPE html>
On 2016/06/08 01:37:21, Yosi_UTC9 wrote:
> Could you use w3c test harness to avoid to have expected text?
> 
> Here is an example:
>
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/editing/s...

Done.

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/editing/SelectionController.cpp (right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/editing/SelectionController.cpp:641: 
On 2016/06/08 01:37:21, Yosi_UTC9 wrote:
> nit: no need to have an extra blank line here.

The assert was not actually right. I removed it.

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/editing/SelectionController.h (right):

https://codereview.chromium.org/2048733002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/editing/SelectionController.h:93: 
On 2016/06/08 01:37:22, Yosi_UTC9 wrote:
> nit: no need to have an extra blank line here.

Done.

[yosin_UTC9, 2016-06-27 04:21:51]

C++ changes are good.
Tests needs to some refinements.

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:14:
if (!window.testRunner || !window.eventSender)
How about:

assert_not_equals(window.testRunner, undefined, 'requires testRunner');
assert_not_equals(window.eventSender, undefined, 'requires eventSender');

to get rid of if-statement and reduce indentation.

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:17:
testRunner.dumpAsText();
We don't need to have |testRunner.dumpAsText()| for testharness.js

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:39:
span.parentNode.removeChild(span);
|span.remove()| is shorter. BTW, you don't need to remove SPAN element.
If you have |<div id="log"></div>|

[tonikitoo, 2016-06-27 15:08:15]

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:14:
if (!window.testRunner || !window.eventSender)
On 2016/06/27 04:21:50, Yosi_UTC9 wrote:
> How about:
> 
> assert_not_equals(window.testRunner, undefined, 'requires testRunner');
> assert_not_equals(window.eventSender, undefined, 'requires eventSender');
> 
> to get rid of if-statement and reduce indentation.

Done.

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:17:
testRunner.dumpAsText();
On 2016/06/27 04:21:50, Yosi_UTC9 wrote:
> We don't need to have |testRunner.dumpAsText()| for testharness.js

Done.

https://codereview.chromium.org/2048733002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-no-drag-n-drop.html:39:
span.parentNode.removeChild(span);
On 2016/06/27 04:21:51, Yosi_UTC9 wrote:
> |span.remove()| is shorter. BTW, you don't need to remove SPAN element.
> If you have |<div id="log"></div>|

Done.

[yosin_UTC9, 2016-06-28 01:09:14]

lgtm w/ small nits in tests.

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html:13:
var span = document.getElementsByTagName('span')[0];
nit: document.querySelector('span') is shorter.
It is better to use "id" attribute and document.getElementById() or
document.querySelector('#foo') to be more specific.

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html:16:
var img = document.getElementsByTagName('img')[0];
nit: document.querySelector('img') is shorter.
It is better to use "id" attribute and document.getElementById() or
document.querySelector('#foo') to be more specific.

[tonikitoo, 2016-06-29 02:49:51]

Addressed your suggestion for all 3 test files.

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html
(right):

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html:13:
var span = document.getElementsByTagName('span')[0];
On 2016/06/28 01:09:14, Yosi_UTC9 wrote:
> nit: document.querySelector('span') is shorter.
> It is better to use "id" attribute and document.getElementById() or
> document.querySelector('#foo') to be more specific.

Done.

https://codereview.chromium.org/2048733002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/shift-drag-selection-on-image-triggers-drag-n-drop.html:16:
var img = document.getElementsByTagName('img')[0];
On 2016/06/28 01:09:14, Yosi_UTC9 wrote:
> nit: document.querySelector('img') is shorter.
> It is better to use "id" attribute and document.getElementById() or
> document.querySelector('#foo') to be more specific.

Done.

[tonikitoo, 2016-06-29 02:50:07]

The CQ bit was checked by tonikitoo@igalia.com

[tonikitoo, 2016-06-29 02:50:07]

The patchset sent to the CQ was uploaded after l-g-t-m from yosin@chromium.org
Link to the patchset: https://codereview.chromium.org/2048733002/#ps60001
(title: "Patch for landing")

[commit-bot: I haz the power, 2016-06-29 02:50:28]

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-06-29 02:50:29]

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

[commit-bot: I haz the power, 2016-06-29 02:50:30]

The author tonikitoo@igalia.com has not signed Google Contributor License
Agreement. Please visit https://cla.developers.google.com to sign and manage
CLA.

[Manuel Rego, 2016-06-29 05:09:11]

On 2016/06/29 02:50:30, commit-bot: I haz the power wrote:
> The author mailto:tonikitoo@igalia.com has not signed Google Contributor
License
> Agreement. Please visit https://cla.developers.google.com to sign and manage
> CLA.

This is weird, in theory we've a corporate CLA for Igalia,
and any @igalia.com address should be able to contribute:
https://chromium.googlesource.com/chromium/src.git/+/master/AUTHORS#725

Maybe the issue here is that your account tonikitoo@igalia.com
has not commit permissions yet? Just wondering.

[tonikitoo, 2016-06-29 05:11:50]

On 2016/06/29 05:09:11, Manuel Rego wrote:
> On 2016/06/29 02:50:30, commit-bot: I haz the power wrote:
> > The author mailto:tonikitoo@igalia.com has not signed Google Contributor
> License
> > Agreement. Please visit https://cla.developers.google.com to sign and manage
> > CLA.
> 
> This is weird, in theory we've a corporate CLA for Igalia,
> and any @igalia.com address should be able to contribute:
> https://chromium.googlesource.com/chromium/src.git/+/master/AUTHORS#725
> 
> Maybe the issue here is that your account mailto:tonikitoo@igalia.com
> has not commit permissions yet? Just wondering.

Also found it strange, specially because my other two accounts
(tonikitoo@chromium and a1.gomes@samsung) have the committer bit on them :(.

[Manuel Rego, 2016-06-29 05:43:47]

Adding @svillar in CC as he usually dealt with the CLA stuff in the past.

[Manuel Rego, 2016-06-30 06:26:33]

rego@igalia.com changed reviewers:
+ rego@igalia.com

[Manuel Rego, 2016-06-30 06:26:34]

+dannyb

In theory Igalia has an "all members" corporate CLA.
I remember this CL when I added Igalia to the AUTHORS file:
https://codereview.chromium.org/166663002#msg7

At that time, @svillar and @dannyb exchanged some private mails
to change the Igalia CLA to "all members".

Daniel please could you check what's going on? Thanks!

[blink-reviews, 2016-06-30 06:34:48]

+signcla-eng


On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:

> +dannyb
>
> In theory Igalia has an "all members" corporate CLA.
> I remember this CL when I added Igalia to the AUTHORS file:
> https://codereview.chromium.org/166663002#msg7
>
> At that time, @svillar and @dannyb exchanged some private mails
> to change the Igalia CLA to "all members".
>
> Daniel please could you check what's going on? Thanks!
>
> https://codereview.chromium.org/2048733002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-06-30 06:34:52]

+signcla-eng


On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:

> +dannyb
>
> In theory Igalia has an "all members" corporate CLA.
> I remember this CL when I added Igalia to the AUTHORS file:
> https://codereview.chromium.org/166663002#msg7
>
> At that time, @svillar and @dannyb exchanged some private mails
> to change the Igalia CLA to "all members".
>
> Daniel please could you check what's going on? Thanks!
>
> https://codereview.chromium.org/2048733002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[blink-reviews, 2016-06-30 06:38:36]

So, before signcla existed, when it was just a spreadsheet, i did indeed
update the spreadsheet to reflect that everyone was authorized.

I'm pretty sure corporate CLA were not initially ported into signcla
because it requires setup on the part of the corporation (in particular,
they have to set up a google group, and that group's membership is used to
determine who is authorized).

It's easiest to go through the setup workflow for corporate clas, click
through it, and we can just approve the cla.

I'm pretty sure working around this would take more time than that :)

(+signcla-eng, xam so they know what's up)

On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:

> +dannyb
>
> In theory Igalia has an "all members" corporate CLA.
> I remember this CL when I added Igalia to the AUTHORS file:
> https://codereview.chromium.org/166663002#msg7
>
> At that time, @svillar and @dannyb exchanged some private mails
> to change the Igalia CLA to "all members".
>
> Daniel please could you check what's going on? Thanks!
>
> https://codereview.chromium.org/2048733002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-06-30 06:38:36]

So, before signcla existed, when it was just a spreadsheet, i did indeed
update the spreadsheet to reflect that everyone was authorized.

I'm pretty sure corporate CLA were not initially ported into signcla
because it requires setup on the part of the corporation (in particular,
they have to set up a google group, and that group's membership is used to
determine who is authorized).

It's easiest to go through the setup workflow for corporate clas, click
through it, and we can just approve the cla.

I'm pretty sure working around this would take more time than that :)

(+signcla-eng, xam so they know what's up)

On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:

> +dannyb
>
> In theory Igalia has an "all members" corporate CLA.
> I remember this CL when I added Igalia to the AUTHORS file:
> https://codereview.chromium.org/166663002#msg7
>
> At that time, @svillar and @dannyb exchanged some private mails
> to change the Igalia CLA to "all members".
>
> Daniel please could you check what's going on? Thanks!
>
> https://codereview.chromium.org/2048733002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[blink-reviews, 2016-06-30 14:44:05]

Igalia has already been ported into the new system.  The contributor group
is igalia-google-contributors@googlegroups.com, and the point of contact we
have on file is Martin Robinson <mrobinson@igalia.com>.  If some
contributions are getting rejected, they likely just need to be added to
this group.  We are no longer able to support "all members" for a
corporation.

On Wed, Jun 29, 2016 at 11:38 PM, Daniel Berlin <dannyb@google.com> wrote:

> So, before signcla existed, when it was just a spreadsheet, i did indeed
> update the spreadsheet to reflect that everyone was authorized.
>
> I'm pretty sure corporate CLA were not initially ported into signcla
> because it requires setup on the part of the corporation (in particular,
> they have to set up a google group, and that group's membership is used to
> determine who is authorized).
>
> It's easiest to go through the setup workflow for corporate clas, click
> through it, and we can just approve the cla.
>
> I'm pretty sure working around this would take more time than that :)
>
> (+signcla-eng, xam so they know what's up)
>
> On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:
>
>> +dannyb
>>
>> In theory Igalia has an "all members" corporate CLA.
>> I remember this CL when I added Igalia to the AUTHORS file:
>> https://codereview.chromium.org/166663002#msg7
>>
>> At that time, @svillar and @dannyb exchanged some private mails
>> to change the Igalia CLA to "all members".
>>
>> Daniel please could you check what's going on? Thanks!
>>
>> https://codereview.chromium.org/2048733002/
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-06-30 14:44:06]

Igalia has already been ported into the new system.  The contributor group
is igalia-google-contributors@googlegroups.com, and the point of contact we
have on file is Martin Robinson <mrobinson@igalia.com>.  If some
contributions are getting rejected, they likely just need to be added to
this group.  We are no longer able to support "all members" for a
corporation.

On Wed, Jun 29, 2016 at 11:38 PM, Daniel Berlin <dannyb@google.com> wrote:

> So, before signcla existed, when it was just a spreadsheet, i did indeed
> update the spreadsheet to reflect that everyone was authorized.
>
> I'm pretty sure corporate CLA were not initially ported into signcla
> because it requires setup on the part of the corporation (in particular,
> they have to set up a google group, and that group's membership is used to
> determine who is authorized).
>
> It's easiest to go through the setup workflow for corporate clas, click
> through it, and we can just approve the cla.
>
> I'm pretty sure working around this would take more time than that :)
>
> (+signcla-eng, xam so they know what's up)
>
> On Wed, Jun 29, 2016 at 11:26 PM, <rego@igalia.com> wrote:
>
>> +dannyb
>>
>> In theory Igalia has an "all members" corporate CLA.
>> I remember this CL when I added Igalia to the AUTHORS file:
>> https://codereview.chromium.org/166663002#msg7
>>
>> At that time, @svillar and @dannyb exchanged some private mails
>> to change the Igalia CLA to "all members".
>>
>> Daniel please could you check what's going on? Thanks!
>>
>> https://codereview.chromium.org/2048733002/
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[tonikitoo, 2016-06-30 17:48:56]

The CQ bit was checked by tonikitoo@igalia.com

[commit-bot: I haz the power, 2016-06-30 17:49:23]

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-06-30 17:57:21]

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

[commit-bot: I haz the power, 2016-06-30 17:57:22]

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...)

[Rick Byers, 2016-06-30 20:13:53]

On 2016/06/30 17:57:22, commit-bot: I haz the power wrote:
> 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...)

core/input LGTM

[tonikitoo, 2016-06-30 20:16:22]

The CQ bit was checked by tonikitoo@igalia.com

[commit-bot: I haz the power, 2016-06-30 20:17:26]

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-06-30 22:23:28]

Description was changed from

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
==========

to

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
==========

[commit-bot: I haz the power, 2016-06-30 22:23:30]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-06-30 22:24:51]

Description was changed from

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023
==========

to

==========
Selecting with shift+drag results in unexpected drag-n-drop

Whenever user tries to extend an existing text selection by dragging the mouse
(left button hold) with shift key pressed, Blink enters drag-n-drop mode.

This behavior does not match common editing behavior out there, including other
engines' (WebKit, Gecko/Firefox, Opera/Presto and IE).

Patch changes Blink so that whenever one extends a selection with mouse
and shift key pressed off of a #text node, it does not enter drag-n-drop mode.

Additionally, patch also adds some further tests to ensure that when
selection is extended off of either a link or an image, drag-n-drop does
get triggered, no matter if shift key is pressed.

Associated WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=155314.

BUG=142023

Committed: https://crrev.com/40285d7edd6ab066b3a9c8756416ea7395b2eb55
Cr-Commit-Position: refs/heads/master@{#403315}
==========

[commit-bot: I haz the power, 2016-06-30 22:24:53]

Patchset 4 (id:??) landed as
https://crrev.com/40285d7edd6ab066b3a9c8756416ea7395b2eb55
Cr-Commit-Position: refs/heads/master@{#403315}