1513778 - Gmail drop file bug in newer versions of Firefox

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P1)

Description

[moonlight.yang]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

1. Open Google gmail page and compose an email in Firefox 60.4.0esr 64-bit or 64.0 64-bit in Debian 9 GNU/Linux OS.
2. Drag and drop a file from the file manager to Firefox gmail page.


Actual results:

The "Drop File Here" frame appears but the dropping fails. The "Drop File Here" frame persists even after the dropping failure, interfering with email editing. The composing email has to be either closed or be refreshed by reloading the page to make it editable again. Sometimes re-dropping the file makes it work.


Expected results:

The dropped file should be accepted as an attachment to the composing email and you should be able to continue editing the email. Google chrome and Firefox 52.9.0 64-bit work as expected.

Comment 1

[Kanchan Kumari QA]

I could reproduce this issue on Ubuntu 16.04

User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Comment 2

[Andreas Farre [:farre]]

Kanchan I'm having trouble reproducing this consistently, were you able to do it every time or did you need to try repeatedly?

Neil, not sure who to bounce this to, but the one time I got this to reproduce it totally wreaked Gmail, I'm thinking P1 for this?

Comment 3

[Kanchan Kumari QA]

(In reply to Andreas Farre [:farre] from comment #2)
> Kanchan I'm having trouble reproducing this consistently, were you able to
> do it every time or did you need to try repeatedly?
> 
> Neil, not sure who to bounce this to, but the one time I got this to
> reproduce it totally wreaked Gmail, I'm thinking P1 for this?

I wasn't able to reproduce consistently. I remember I tried 7-8 times and I could reproduce ~5 times.

Comment 4

[Neil Deakin]

Some debugging suggests that the target frame passed to EventStateManager::PostHandleEvent is null for the dragover event when this bug occurs, preventing the default handling from occuring. The target frame is correct for PreHandleEvent. I think this means that the frame goes away during the event, which seems likely considering the 'Drop Files Here' panel that appears during dragover.

Note also that this bug only happens on Linux, likely due to the more asynchronous nature of drag and drop there.

There is a check near the beginning of PostHandleEvent which returns early when the frame is null. The bug doesn't happen when this check is disabled.

The post-processing in dragover doesn't require a frame though (except for the scrolling part which isn't relevant here), so perhaps the fix is just to add eDragOver to the check at https://searchfox.org/mozilla-central/source/dom/events/EventStateManager.cpp#2954 ?

Comment 5

[Neil Deakin]

Attachment: Dragenter and dragover don't need a frame for their default handling to occur

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1442b1bf2d6d
dragenter and dragover events don't need a frame for their default handling to occur, r=smaug

Comment 7

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/1442b1bf2d6d

Comment 8

[Florencia Di Ciocco, NI to vbalducci]

Hi Neil, I was able to reproduce the bug on

1. nightly version previous to the solving date (12/12/2018)
2. latest nightly (5/23/2019)
3. and latest firefox Release (67).

The bug remains in all of them. I used Ubuntu 16.04 32 bits. I attach the screenshots. Please let me know how to proceed.

Best regards, Flor.

Comment 9

[Florencia Di Ciocco, NI to vbalducci]

Attachment: Screenshots of Florencia Di Ciocco.zip

Comment 10

[Neil Deakin]

Please file a new bug.

Comment 11

[Florencia Di Ciocco, NI to vbalducci]

Hi,

Sorry for the delay, I'll mark this bug as verified fixed since I've opened bug 1554182 to keep track of thi bug's progress.

Regards, Flor.