1241856 - Dragging an email is still selecting text in Gmail

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[v1tesse]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160120154102

Steps to reproduce:

1. Log into Gmail (I made sure to test this with add-ons disabled).
2. Hold left click on an e-mail.
3. Drag it anywhere.


Actual results:

It moves (drags) the e-mail, but it also selects the text around it.


Expected results:

It should just drag the e-mail.

Comment 1

[v1tesse]

Attachment: Drag_selects_text.jpg

This is how it looks for me.

Comment 2

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Hi Vitesse,

I have tested this issue on latest Firefox (44.0) release and latest Nightly (47.0a1) release and I have managed to reproduce it. 

Firefox:44.0, Build ID: 20160123151951, User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Firefox: 47.0a1, Build ID: 20160201030241, User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Considering this I will assign a component to it.

Thanks,
Cosmin.

Comment 3

[Andrew Overholt [:overholt]]

Neil, is this your wheelhouse?

Comment 4

[Neil Deakin]

Drag and drop API isn't being used here. Likely doing something with mouse events and not cancelling the event. Brief testing shows that the mousedown event isn't cancelled when the selection handling code is run at nsFrame::HandlePress.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Added to my todo list

Comment 7

[Alice0775 White]

I can also reproduce on Microsoft Edge 38.14393.0.0 Windows10 home 64bit

Comment 8

[Andrew Overholt [:overholt]]

smaug, do you have any ideas as to what's up here?

Comment 9

[Andrew Overholt [:overholt]]

Mike, given comment 4 and comment 7 it seems like this may be a website issue. Can you or someone on your team work your magic and investigate?

Comment 10

[Mike Taylor [:miketaylr]]

Tom, can you take a look?

Comment 11

[Thomas Wisniewski]

Sure. Stepping through the debugger in Chrome, it looks like preventDefault is indeed never being called on mousedown. I'm not sure how Chrome manages to stop the text from being selectable despite this, as I don't see them applying -webkit-user-select:none to the elements either (or if they are, it's not showing up in their CSS inspector just after the mousedown handler is called).

However, calling preventDefault on the event does fix things for Firefox. Just run this in the console after page-load to see it in action (note of course that closure_lm_650743 changes names with page reload, so you can't just blindly copy-paste):

>var Cp = $('.Cp');
>var Cp_handler = Cp.closure_lm_650743.ha.mousedown[0].listener;
>Cp.closure_lm_650743.ha.mousedown[0].listener = function() {
>    var rv = Cp_handler.apply(this, arguments);
>    var evt = arguments[0];
>    if (evt.type == "mousedown") evt.preventDefault();
>    return rv;
>}

The actual mousedown handler is the following function, which does seem to try to preventDefault if the mousedown event isn't specially handled by the Gsb() function (which does not seem to preventDefault itself).

> (in rs=AHGWq9C8-1m4aAGes0vxQcOlrVA_wjDm-A.html)
> 
>IA.prototype.$a = function(a) {
>    var b = a.type;
>    if ("mousedown" != b || ud(a, 0) || ud(a, 2))
>        if ("click" != b && "dblclick" != b || ud(a, 0)) {
>            a.ra = !1;
>            var c = this.tNa(a.target);
>            c ? "click" == b || "dblclick" == b ? Gsb(this, a, c) : "keydown" == b ? Gsb(this, a, c) : "mouseover" == b ? this.UMa(a, c) : "mouseout" == b ? this.TMa(a, c) : "mousedown" == b ? Gsb(this, a, c) : "contextmenu" == b && Gsb(this, a, c) : "mousedown" == b && a.preventDefault();
>            // ** snipped code for size **
>        }
>    }
>};

Based on this, it may be a trivial fix for them (just call preventDefault on *all* mousedowns in that function, whether Gsb() is called as well or not).

Comment 12

[Andrew Overholt [:overholt]]

Thanks for the analysis! Do you/WebCompat have contacts on the GMail team or should we go through email?

Comment 13

[Thomas Wisniewski]

I'm actually not sure. karl, would you happen to know if we have contacts for GMail for such issues?

Comment 14

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to Thomas Wisniewski from comment #13)
> I'm actually not sure. karl, would you happen to know if we have contacts
> for GMail for such issues?

Great work, Thomas.

A DL exists of which members of Gmail (Sanda and Martin) are active.

A few steps though:
1. Email :jst to add you to the DL (it's one of the few that I don't admin)
2. Email the DL with the info and fix addressing it to Sanda, Martin and the Gmail team 

Myself, Karl or :miket can provide more info via email as needed.

Comment 15

[Karl Dubost💡 :karlcow]

Google has been contacted by email.

Comment 16

[skroon]

Is this perhaps also due to the same problem (on Google keep, also a selecting issue when dragging cards): https://bugzilla.mozilla.org/show_bug.cgi?id=1285171

Comment 17

[Andrew Overholt [:overholt]]

(In reply to skroon from comment #16)
> Is this perhaps also due to the same problem (on Google keep, also a
> selecting issue when dragging cards):
> https://bugzilla.mozilla.org/show_bug.cgi?id=1285171

I think you're right.

Comment 18

[skroon]

It's now been almost a month since :karlcow reported Google had been emailed, without any update on that front.  Have they acknowledged the email or indicated they'll look into this?

Comment 19

[Botond Ballo [:botond]]

(In reply to skroon from comment #18)
> It's now been almost a month since :karlcow reported Google had been
> emailed, without any update on that front.  Have they acknowledged the email
> or indicated they'll look into this?

They indicated at the time that a bug was filed in their internal bug tracker for this issue, and it was added to their regular bug triage queue. We haven't had an update since (there may be updates in their internal tracker, but we don't have access to that).

Comment 20

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

Thomas based on your analysis in Comment 11 are you able to retest? Perhaps this has moved internal within the Gmail team - but they haven't alerted us.

Comment 21

[Thomas Wisniewski]

(In reply to Desigan Chinniah [:cyberdees] [:dees] [London - GMT] from comment #20)
> Thomas based on your analysis in Comment 11 are you able to retest?

Nope, the text is still selected for me in GMail as before, in both release and nightly. Calling preventDefault as in comment #11 still seems to fix it, too, so I don't think anything has changed (at least not on the public version of GMail I can access).

Comment 22

[Mike Taylor [:miketaylr]]

Karl, can we bring this up to Google again please? It seems like nothing has been fixed here and it's been ~3 months. Thanks!

Comment 23

[Karl Dubost💡 :karlcow]

I will. 3 months ago.

> Thanks for the report, I've filed http://b/32761364 and added it to our regular bug triage queue. Thanks to Thomas for the analysis!

I asked about the status today.

Comment 25

[Kamil Jozwiak [:kjozwiak]]

Results while going through bug#881989 to see if it was still a valid issue:

I can still reproduce this on all three platforms with the latest builds of fx.

Quick example of the issue: https://youtu.be/vSZJBLublAI

Builds:

* fx54.0, buildid: 20170608105825, changeset: e832ed037a3c - reproduced
* fx55.0b3, buildid: 20170619071954, changeset: be4a0ad5d6ca - reproduced
* fx56.0a1, buildid: 20170620030208, changeset: 7a6baa6cca32 - reproduced

Platforms:

* macOS 10.12.5 x64 - reproduced
* Ubuntu 16.04.2 LTS x64 VM - reproduced
* Win 10 x64 VM - reproduced

Comment 27

[Sergiu Logigan [:sergiu]]

On the new interface of Gmail, the issue is no longer reproducible.