Closed Bug 1513778 Opened 3 years ago Closed 3 years ago
Gmail drop file bug in newer versions of Firefox
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.
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
Status: UNCONFIRMED → NEW
Component: Untriaged → Drag and Drop
Ever confirmed: true
Product: Firefox → Core
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?
(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.
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 ?
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Priority: -- → P1
Attachment #9032738 - Flags: review?(bugs) → review+
Pushed by firstname.lastname@example.org: 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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.