Closed Bug 1465513 Opened 7 years ago Closed 4 years ago

dragging and dropping a document from Windows into Firefox often crashes Firefox

Categories

(Core :: Widget: Win32, defect, P2)

Product:
Core
Component:
Widget: Win32
Version:
60 Branch
Platform:
x86
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
86 Branch
Tracking Flags:
Tracking Status
firefox-esr78 86+ fixed
firefox76 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- fixed

People

(Reporter: omgitsraven, Assigned: bobowen)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

firefox.exe.3344.dmp.log
402.81 KB, text/plain
Details
Bug 1465513: Call IDropTargetHelper::DragLeave before IDropTargetHelper::DragEnter. r=dmajor!
48 bytes, text/x-phabricator-request
jcristau
: approval-mozilla-esr78+
Details | Review
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: Drag a file from a Windows 10 folder into Firefox, i.e. into a file upload field, or into an element that's set to receive dropped files. Sometimes it works perfectly, and other times the bug happens -- it feels like roughly a 50% chance. (This has been happening for probably nearly a year, but I don't remember exactly when it started unfortunately.) Actual results: Firefox immediately freezes (then crashes a few seconds later). Also, whenever this happens, for some reason the thumbnail surrounding the cursor during the drag shows a screenshot of a page currently open in one of my firefox tabs, instead of showing the document being dragged. Expected results: The element being dragged to should receive the document I'm dragging to it, instead of crashing Firefox. (Also, the thumbnail around the cursor should show the document that I'm dragging, instead of a screenshot of one of my tabs.)
Hi! I've tried to reproduce the issue mentioned above but without success, with Release version 60.0.1 Build ID:20180516032328. I've tried by uploading different files (different sizes) on a google drive, by drag and drop, but no freeze or crash occurred. If the issue is still reproducible at your side please try and attach us a crash report so that we can investigate further. Here you can find info related on how to send a crash report: https://support.mozilla.org/en-US/kb/mozillacrashreporter
Flags: needinfo?(omgitsraven)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
Actually, that's another interesting thing I forgot to mention -- when this bug happens, the Mozilla Crash Reporter DOESN'T appear; instead some Microsoft one does? I had assumed that that was some new Windows feature that made the Mozilla Crash Reporter obsolete, but if you're suggesting that I should still be using it then I'm not sure how to proceed.
Hey! Even if the crash reporter doesn't appear, one can check if there are crash reports available, if in the browser address bar one types about:crashes and presses Enter. This info is available also on the link I've mentioned in comment 1.
Whoops, sorry, I missed that part! OK, I'll check there next time the crash happens... (I do have lots of unsubmitted crash reports apparently, but I don't remember if they were all related to the drag-and-drop crash, and I don't want to confuse the issue.)
Well, here's some bad news: I just had the crash again, and it has NOT added a new crash report to about:crashes (in either 'submitted' or 'unsubmitted'). One other minor thing I noticed that may or may not be relevant: I noticed that the image that replaced the proper thumbnail this time was a screenshot of a tab that was in a separate firefox window that I had closed maybe an hour ago. I hadn't considered that it might be related to having had multiple windows open at some point, but I'll keep my eye out for that going forward.
Flags: needinfo?(omgitsraven)
Thank you for the feedback and for taking the time to report this. I've tried again to reproduce the issue, without success, on the latest Nightly v.62.0a1 BuildID: 20180621013659, using the same steps as in Comment 1. Given the fact that you still managed to reproduce the issue but couldn't get a crash report, I would suggest the following: 1. Make sure you have the latest updated version of Firefox 2. If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager 3. If the issue is still reproducible on the latest Release version please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem. 4. If the issue is present on Firefox Nightly also and still no crash report is available, please give us a screen recording, just to make sure that we understand the correct issue (you can use this app for screen recording https://www.screenpresso.com/)
Flags: needinfo?(omgitsraven)
Hi, Marking this as Resolved: Incomplete due to the lack of response from the reporter. If the issue is still reproducible with the latest Firefox version, feel free to reopen the bug with more information.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Just checking in that this hasn't happened to me since my last post, even though I'm not sure what changed. If it turns out to happen again I'll reopen though, thanks.
Flags: needinfo?(omgitsraven)
OK, after months of it not happening, it finally happened to me again just now. Once again, no new about:crashes, submitted or unsubmitted. If it continues being months between incidents like this then it's probably not worth worrying about, but I thought I'd mention that it definitely hasn't totally gone away, at least.
Just happened again; this is probably the last time I'm going to mention it unless I discover some new information, but I thought the relative proximity of these two was worth noting given how big the gap was just before this. Weird.

Hi, I have this exact same issue, it happens very rarely, but it's quite annoying when it happens.

I don't have much more information than the original reporter, but it usually seems to happen on the GitHub releases upload page, specifically where it says "Attach binaries by dropping them here or selecting them."

I'm not so sure if this affects other sites, I'm pretty sure it does, but I can't be too sure. I haven't ever seen it happen on Google Drive. It doesn't seem to be with any files in particular, and restarting the browser seems to work just fine. Just like the original reporter, it freezes, crashes, and then it doesn't create any crash report at all.

Hi,

The exact same thing happens to me too. It's not easy to reproduce and it's not so often. It usually happens when I do my first drag and drop in a while. If the first drop is successful, then the next will probably succeed too. If I try again after a few hours, there is a good chance that it will crash. It can happen anywhere. On WordPress's media manager or any other (non-WP) site.
There is no log on the crash report either. On every Firefox update, I hope that it will be fixed, but every time it happens again.

Also happens here from time to time, using 75.0 (64-bit).

It is very annoying as it usually happens after I write a long post and the last step is to upload an attachment.

Component: Untriaged → File Handling

Chiming in again after a couple of years to say, I've bought a new machine since then, and I THOUGHT that I'd left the bug behind on my old machine, but: it just happened to me again (on my new machine)!

I get this issue about two-three times a day, currently on 76.0b8 (64-bit)
I've had this issue on and off for a number of years too, but it has been very common in the past couple weeks, but I have been using drag and drop more frequently recently.
In every instance of this crash, the file (most usually an image) being dropped into the document area will display a render of any of the active tabs, with the potential of it possibly even a previously closed tab.

The windows event logs the APPCRASH event with an Access Violation error when interfacing with the SHELL32 module.
Not that I understand it very well, but the fault offset for all logged events is Fault offset: 0x0000000000227f1b

Replication has been difficult, while I'm sure there's a logical explanation to what causes the issue, my experience with it has been a luck of the draw as to when the browser decided to crash

Same issue here, it happens sparingly but does so enough that makes it annoying when it happens, needing all your FireFox windows to repoen and load. I would be nice to reopen this issue.

FireFox 76.0 (64-bit), Windows 10 Build 2004

No crash report created in about:crashes.

Event Viewer reports an Application Error:

Faulting application name: firefox.exe, version: 76.0.0.7424, time stamp: 0x5ea9dcdd
Faulting module name: SHELL32.dll, version: 10.0.19041.153, time stamp: 0x03d256b1
Exception code: 0xc0000005
Fault offset: 0x0000000000243b5f
Faulting process ID: 0xd84
Faulting application start time: 0x01d6244137ce5019
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\WINDOWS\System32\SHELL32.dll
Report ID: fc2800d9-52bb-48df-8af8-409a0d407624
Faulting package full name: 
Faulting package-relative application ID:

I've been having the same issue for awhile now, hope these details help:

  • Firefox crashes specifically at the moment the dragging cursor enters the Firefox window perimeter (i.e. not related to "dropping")
  • If it doesn't crash doing a drag/drop, it will not crash as long as you're actively using the session; The "dice gets rolled" when you're away from the computer for awhile (e.g. after it locks and you login again)
  • Someone mentioned this, it seems to have something to do with the rendering of the dragged item. When "picking up" an object in windows, sometimes it shows the item icon being dragged, and it seems "safe" to drag into the Firefox window. Other times, it may render some kind of preview of the object, and dragging those into the Firefox window might cause it to crash.
  • Happens on Windows 10, but not on Windows 7

want to clarify a couple of things about foxuser's points:

  • my computer doesn't 'lock' at all, I don't even have a screen saver, so it isn't related to locking/logging back in
  • about the 'preview', I mentioned this earlier in the thread, but for me when the crash happens, the file icon that I'm dragging becomes an image of one of the other tabs that I have open.

sorry, I just realised I misspoke slightly in my first post—my screens DO turn off after a period of inactivity, but I think it's purely the screens; I definitely don't log back in upon returning, nothing acts like I've just "resumed" in any way

sorry again: I meant "in my first point (in the previous post)", not "in my first post". sorry for the flood just now.

omgitsraven, can you reopen the ticket? I assume nobody will look at this because it's considered resolved. I'm going to see if I can come up with steps to reliably reproduce

Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---

I wasn't aware that was something I had the power to do, but you're right, apparently I do...

I just set it to 'unconfirmed', is that the way to approach this? I've never done this before

(In reply to omgitsraven from comment #22)

I wasn't aware that was something I had the power to do, but you're right, apparently I do...

I just set it to 'unconfirmed', is that the way to approach this? I've never done this before

status-firefox76: --- → affected

I'm getting this a lot recently. Firefox 77.0b8 (64-bit), Microsoft Windows 10 Pro, 10.0.18362 Build 18362. As with others, I'm not getting any reports in about:crashes.

Have had this a lot over the years, to the point where I've learned to, under no circumstances, ever drag anything into a Firefox window. Unfortunately, sometimes when I'm trying to drag something into another application from Explorer, I accidentally pass over a Firefox window, instantly crashing my session. No crash reports (Windows 10 Pro, Firefox 76.0.1). But it also happens on Mac OS (currently inaccessible to me, as that is at work and the pandemic means I've not been there in 2 months).

It almost never crashes when the session is relatively new, but the longer Firefox is open, the greater the chance of the crash - if it's open for a few hours or days, the crash is absolutely certain to happen. This single bug is responsible for more than 90% of the crashes I experience with Firefox. In fact, it now seems to be the only thing that crashes Firefox.

Without reports in about:crashes or reliable steps to reproduce, it's going to be very hard to track this down. Gabriele, what can we do to get more crash info here?

Flags: needinfo?(gsvelto)

Yes, since this is apparently triggering the Windows Error Reporter dialog we can get a local minidump using it. Here's the steps required to do it:

  • Using regedit.exe create the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps registry key. The key can be left empty as the default settings are fine.
  • Launch Firefox and wait for it to crash
  • Go into C:\Users\<username>\AppData\Local\CrashDumps and see if there's a minidump in there (.dmp extension)
  • Send the minidump to me via e-mail so that I can analyze it

Important note: do not attach the minidump to this bug. It may contain sensitive information so it should not be public.

More information on how WER works can be found here but the above steps should be enough to catch the issue.

Flags: needinfo?(gsvelto)

If people who are seeing this regularly could follow the steps in comment 27 and respond here when they send Gabriele a crash, that'd be really useful.

Severity: normal → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(shd)
Flags: needinfo?(adam)

Thanks for the heads-up. I've created the registry key, and will look for a dump the next time I get a drag-and-drop crash.

Flags: needinfo?(adam)

S1 or S2 bugs need an assignee - could you find someone for this bug?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Tim Spurway [:tspurway] from comment #30)

S1 or S2 bugs need an assignee - could you find someone for this bug?

Without knowing what is crashing, it's not clear this is the right component or who is a good assignee to fix it.

Flags: needinfo?(gijskruitbosch+bugs)

I can take it for the analysis, then I'll hand it over to whoever will have to fix it.

Someone's volunteered as tribute! ;-)

Assignee: nobody → gsvelto

Firefox has been rather stable since escalating this bug, but it finally crashed. Minidump sent to gsvelto

Faulting application name: firefox.exe, version: 76.0.1.7432, time stamp: 0x5eb403e6
Faulting module name: SHELL32.dll, version: 10.0.17763.1131, time stamp: 0x7174ec2c
Exception code: 0xc0000005
Fault offset: 0x000000000022324b
Faulting process id: 0xd10
Faulting application start time: 0x01d63504aaf49d6b
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\Windows\System32\SHELL32.dll
Report Id: f3857b67-1318-4ed6-a1b3-cfca4b1762db
Faulting package full name: 
Faulting package-relative application ID:

Here's the full stack trace from the minidump. This is the first ten frames of the crashing thread:

 0  shell32.dll!void CDragDropHelper::MakeRectOpaqueOnBitmap(struct tagRECT const &) + 0x37
    rax = 0x000001bb016d0000   rdx = 0x0000002af81fd2a8
    rcx = 0x0000000000008c8f   rbx = 0x0000002af81fd340
    rsi = 0x0000000000000001   rdi = 0x0000000000000002
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fd248
     r8 = 0x0000000000000003    r9 = 0x0000000000000671
    r10 = 0x000001bafede7430   r11 = 0x0000002af81fd220
    r12 = 0x00000000000001ac   r13 = 0x00007ffc5ee90fd0
    r14 = 0x000001bafede7430   r15 = 0x0000000000000001
    rip = 0x00007ffc5cc2324b
    Found by: given as instruction pointer in context
 1  shell32.dll!void CDragDropHelper::_DrawDescriptionLine(int,int,unsigned short const *,struct tagRECT const *) + 0xbc
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fd250
    rip = 0x00007ffc5cc2515c
    Found by: stack scanning
 2  shell32.dll!void CDragDropHelper::_DrawDefaultImageAndDescription + 0x1e6
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fd2f0
    rip = 0x00007ffc5cc2503a
    Found by: call frame info
 3  shell32.dll!long CDragDropHelper::_AddInfoToWindow + 0x567
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fd5b0
    rip = 0x00007ffc5cc2401f
    Found by: call frame info
 4  shell32.dll!virtual long CDragDropHelper::DragOver(struct tagPOINT *,unsigned long) + 0x174
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fdac0
    rip = 0x00007ffc5cc22ea4
    Found by: call frame info
 5  xul.dll!nsNativeDragTarget::DragOver(unsigned long, _POINTL, unsigned long*) [nsNativeDragTarget.cpp:e2de5f11bc0afd9a3024d32b83cb9f0ada95717a : 325 + 0xe]
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fdb60
    rip = 0x00007ffc153c4563
    Found by: call frame info
 6  ole32.dll!CPrivDragDrop::PrivDragDrop(CallerLocalityIndicator, HWND__*, tagInterfaceData*, unsigned long, unsigned long, _POINTL, unsigned long*, unsigned long, IDataObject*, HWND__*) [getif.cxx : 679 + 0x18]
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fdbe0
    rip = 0x00007ffc5e937410
    Found by: call frame info
 7  rpcrt4.dll!Invoke + 0x73
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fdc30
    rip = 0x00007ffc5df77803
    Found by: call frame info
 8  0x1bb2fe79a10
    rbp = 0x0000002af81fd370   rsp = 0x0000002af81fdc70
    rip = 0x000001bb2fe79a10
    Found by: call frame info
 9  rpcrt4.dll!Invoke + 0x26
    rsp = 0x0000002af81fdc90   rip = 0x00007ffc5df777b6
    Found by: stack scanning
10  rpcrt4.dll!?Ndr64StubWorker@@YAJPEAX0PEAU_RPC_MESSAGE@@PEAU_MIDL_SERVER_INFO_@@PEBQ6AJXZPEAU_MIDL_SYNTAX_INFO@@PEAK@Z + 0xbc6
    rsp = 0x0000002af81fdcd0   rip = 0x00007ffc5dfdb4a6
    Found by: call frame info

There's a few odd things happening here. First of all the crashing function is from a Microsoft library and it seems super-simple. Looking at the crash address it's hard to tell where it's coming from, the closest address is in rax (which should be the address of the tagRECT structure) but it's a fair bit off. The second frame was found by stack scanning which is odd because we have full debug information for this frame, so it should be CFI. Going up the 8th frame is completely borked, there's nothing there. Additionally we should have caught this crash, our exception handler does handle this kind of stuff.

Given the above my guess is that the stack was corrupted somehow - and maybe that's what led to the crash.

The closest Gecko function is this one and I don't see anything odd there, but I'm no widget expert.

Also, we seem to have a bug on file with a crash signature that matches this one, it's bug 1332629.

I've glanced over a few crash reports there and they look similar to this one: the second stack frame is often found by stack scanning and the failure is a write to an address that is between 100Kib and 300KiB off of what's in rax.

I'm reasonably sure that this bug is a duplicate of bug 1332629 and it's most likely a Windows widget issue.

I will try opening the minidump in Visual Studio to see if I get a better stack trace or some other insight there.

(In reply to Gabriele Svelto [:gsvelto] from comment #35)

we should have caught this crash, our exception handler does handle this kind of stuff.

Given the above my guess is that the stack was corrupted somehow - and maybe that's what led to the crash.
...
Also, we seem to have a bug on file with a crash signature that matches this one, it's bug 1332629.

Bug 1332629 certainly appears to be a duplicate. The crash is very abrupt as well; There are no error reporting dialogs (Firefox and Windows) when this occurs, though I'm not sure if that is a result of a local configuration.

Not sure if this helps, but in my experience, it feels like the crashing is related or exacerbated by the virtual desktops feature in Windows 10. Historically, it has also been spontaneously unstable (glitches on desktop switching, unable to enter task view, cannot interact with certain UI elements), and coincides with Firefox crashing in Win10 only. Also, since my first comment in this bug, I reduced the number of virtual desktops I was using from 3 to 2. For those two weeks, Firefox did not crash.

In a bid to replicate the original crash conditions, I went back to 3 virtual desktops, had Firefox open while periodically switching desktops, allowed the system to lock from inactivity, logged back in, switched to the 3rd virtual desktop, opened a new Firefox window, and dragged a URL file toward the browser window. It took about 2-3 cycles of this procedure to cause a crash.

(In reply to foxuser from comment #37)

Not sure if this helps, but in my experience, it feels like the crashing is related or exacerbated by the virtual desktops feature in Windows 10.

That's a useful piece of information. In bug 1332629 quite a few users mentioned dragging across multiple displays. It might be that multi-display support - either virtual or physical - makes the crash most likely.

BTW my analysis in Visual Studio was inconclusive. The stack trace I get is the same and I have no further insight as to how the stack might have been corrupted.

Now that it's mentioned, I did have multiple displays when I would experience this crash. Using virtual desktops was mentioned, but I never used that. Ever since I've only had one disaplay anymore, I haven't had a single crash and I haven't changed anything else, I used to have 3 monitors and now only have one.

Given that we think the issue is in widget, moving over there and flagging Jim M in case he can find someone to help investigate further; there are some clues as to what's going on in the last few comments, though there's more investigation to be done...

Component: File Handling → Widget: Win32
Flags: needinfo?(jmathies)
Product: Firefox → Core

Un-assigning myself now that the investigation is done :-)

Assignee: gsvelto → nobody

Maybe something in the dragdrop object we have to create to support dragging and dropping files. Without a local repo though this is going to be hard to debug.

Flags: needinfo?(jmathies)
Priority: -- → P2

This issue started since a month, I do have mozilla spanning across 2 displays. Probably happens when I drag a file from 1 screen (File Explorer) to another (Firefox - Gmail, tried uploading a document)!

Sorry for my English.

I have exactly the same issue at Firefox 79.0 on Windows 10(x64,19041.388), when Firefox freezes a few seconds and disappeared.

I experienced this just now, and a few times over the past couple years. I'm on Firefox 79.0, Windows 10, I do have two virtual desktops. Happens when I'm dragging a file over, as soon as the mouse hits the Firefox window it closes instantly. No crash reporter, nothing in about:crashes. Lost a review I was writing. :( It's working now though, it's very sporadic.

I've been also able to reproduce this on Linux, not consistently, but there's a good chance when using Slack and then drop a file into a private chat.

I currently run Firefox Developer Edition.

(In reply to captainhypertext from comment #45)

I experienced this just now, and a few times over the past couple years. I'm on Firefox 79.0, Windows 10, I do have two virtual desktops. Happens when I'm dragging a file over, as soon as the mouse hits the Firefox window it closes instantly. No crash reporter, nothing in about:crashes. Lost a review I was writing. :( It's working now though, it's very sporadic.

Could you try reproducing the crash with Firefox Beta? We've introduced a new facility for capturing some crashes that did not generate crash reports in the past, which seems to be your case. If you can repro on beta and it does produce a crash report please link it here.

Flags: needinfo?(captainhypertext)

I finally got annoyed enough at this happening just often enough to search for info about it today. The problem seems to be the same as others are experiencing, but I'll mention the most frustrating point... It's frequently that I'm not even trying to drop the file on firefox, just crossing over it on my screen. I'll make the error reporting change in #27 to see if I can get more info for you.

Windows 10, 2 monitors. Latest non-beta version of FF.

(In reply to kbuxton from comment #48)

I finally got annoyed enough at this happening just often enough to search for info about it today. The problem seems to be the same as others are experiencing, but I'll mention the most frustrating point... It's frequently that I'm not even trying to drop the file on firefox, just crossing over it on my screen. I'll make the error reporting change in #27 to see if I can get more info for you.

Windows 10, 2 monitors. Latest non-beta version of FF.

Firefox 80 should generate a crash report for this crash even w/o the changes from comment 27. Did it generate one when it happened? Can you point us to it? I am currently on vacation but will look into this when I come back.

This happens to me almost once a week. Emailing Gabriele two dump files per comment 27.

I've inspected the minidumps that Dennis sent me and I've got a hunch at what might be going wrong. The crash is happening within Microsoft code called by nsNativeDragTarget::DragOver(). The crash consists of a write at an offset that seems to be outside of a tagRECT structure. We're not handing any pointers to the Microsoft code which we're entering CDragDropHelper::DragOver(), except for a POINT struct we allocate on the stack so we can't be crashing on a wrong or dangling pointer which was my first guess. The method we're crashing in is CDragDropHelper::MakeRectOpaqueOnBitmap(struct tagRECT const &) which is not public but given its name I guess it's writing data into a bitmap.

So it dawned on me: could we be handing bogus coordinates to CDragDropHelper::DragOver() which are leading to the crash once CDragDropHelper::MakeRectOpaqueOnBitmap() tries to use them? Since the crash is happening only with multiple screens it's possible that we're miscalculating the coordinates when the pointer crosses from a screen to another.

Masayuki, do you think my hunch is correct? I have only superficial knowledge of those Windows APIs and I don't know the widget code well enough to confirm my guess.

Flags: needinfo?(masayuki)

Re-reading comment 0 gives a bit more credit to my theory, specifically this part:

for some reason the thumbnail surrounding the cursor during the drag shows a screenshot of a page currently open in one of my firefox tabs, instead of showing the document being dragged

Sounds like we're copying the wrong chunk of memory.

I guess we accidentally set a drag feedback image even though the drop source is not Firefox.

Maybe a workaround: Flip nglayout.enable_drag_images from about:config.

I'm not so familiar with our DnD code and I don't have much time to investigate this right now, though.

In my experience, this might be a bug in Windows. When I was investigating Japanese IME's internal crash, grabbing all related objects didn't help to avoid the crash. According to MSDN, IDropTargetHelper::DragEnter() is designed for IDropTarget::DragEnter() calls this, but we do it from IDropTarget::DragOver(). This might be a trigger of the crash in Windows.

On the other hand, IIRC, we handle DnD asynchronously, so, we might release some COM object before CDragDropHelper creating the image. But I couldn't check it.

If a Microsoft developer checks it, they could tell us what's wrong.

Flags: needinfo?(masayuki)

Thanks to both for the info! Do you know who else could have a look? I know we have a contact with Microsoft and I'll see if somebody can help from their side.

(In reply to Gabriele Svelto [:gsvelto] (PTO until September 5th) from comment #56)

Thanks to both for the info! Do you know who else could have a look? I know we have a contact with Microsoft and I'll see if somebody can help from their side.

It looks like maybe Neil implemented some of this in bug 1309596? Reviews from Olli and Jim Mathies.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #55)

but we do it from IDropTarget::DragOver(). This might be a trigger of the crash in Windows.

So, I am not familiar with this code so maybe I misunderstand, but it looks to me like this can only happen if gDragImageChanged is ever true, which it can only be if something calls DragImageChanged, which is only called from UpdateDragImage which is only called from the datatransfer and through idl, and the only caller I can find is the tabbrowser's ondragstart handler. But I'd expect that code to only run if the drag started on the tabstrip... right? So I don't think that can be it? Unless we're firing bogus dragstart events, which would be a problem for other reasons... :-\

Maybe you can sanity-check my logic?

Flags: needinfo?(gsvelto)

I don't know how this code works, my guesswork in comment 51 is purely based on the analysis of the crash and the user comments here and in many of the crash reports. I think it's better to ask Neil directly if he implemented this.

Flags: needinfo?(gsvelto)

Also we should probably dup bug 1332629 against this one (or vice-versa) because it contains the actual crash signature.

Also one interesting bit: bug 1332629 (which is basically this bug) was first reported on nightly only three weeks after bug 1309596 landed, it's unlikely to be a coincidence.

Neil, could you take a look at this bug? It would appear that maybe it's caused by the code you added in bug 1309596, to update the drag image, when the drag does not in fact start from within Firefox and we somehow end up updating the drag image? See comment 51 / comment 55. It also appears to have something to do with multiple screens being in use, which may or may not point to something to do with coordinate confusion about whether the drag started from within Firefox?

Crash Signature: [@ CDragDropHelper::MakeRectOpaqueOnBitmap ] [@ shell32.dll@0x240ea7 ]
Flags: needinfo?(enndeakin)

I can reproduce this problem consistently on the latest build. I reported it separately as bug 1657524. I'm getting the same backtrace to shell32.dll!CDragDropHelper::MakeRectOpaqueOnBitmap(struct tagRECT const &). I do have 4 monitors, reenforcing Gijs' speculation that it's related to multiple screens. Please let me know how I can help.

(In reply to Aaron Shumate from comment #63)

I can reproduce this problem consistently on the latest build. I reported it separately as bug 1657524. I'm getting the same backtrace to shell32.dll!CDragDropHelper::MakeRectOpaqueOnBitmap(struct tagRECT const &). I do have 4 monitors, reenforcing Gijs' speculation that it's related to multiple screens. Please let me know how I can help.

If you create nglayout.enable_drag_images in about:config as a boolean pref, and set it to false, and restart the browser, does the problem go away?

Flags: needinfo?(trek)

I can reproduce this crash quite easily. It does not require multiple screens.

  1. Open a window with two tabs.
  2. Drag one of the tabs quickly upwards outside the window and drop there.
  3. Drag something from the desktop onto Firefox

It may be the case that we'll need either disable updating the feedback image lazily like this, or limit it to only when the image can be updated while over the Firefox window.

Flags: needinfo?(enndeakin)
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(trek)
Flags: needinfo?(shd)
Flags: needinfo?(captainhypertext)

I'm so glad to hear Neil can reproduce the problem.
The request of me has been unflagged, but in response anyway -- I have been unable to crash Firefox with nglayout.enable_drag_images set to false. I've tested 80.0.1 and the nightly 82.0a1 (2020-09-09) (64-bit).

(In reply to Neil Deakin from comment #65)

I can reproduce this crash quite easily. It does not require multiple screens.

  1. Open a window with two tabs.
  2. Drag one of the tabs quickly upwards outside the window and drop there.
  3. Drag something from the desktop onto Firefox

Although I could not reproduce the crash, I could reproduce "the drag image is a tab thumbnail even if the dragging item is an item from the desktop" phenomenon with this STR.

This is because gDragImageChanged is never cleared unless nsNativeDragTarget::DragOver is called. Step 2 in the STR will end the drag session without firing a dragover event. Therefore the next drag session at step 3 will try to set the outdated drag image when it fires a dragover event. I guess it causes a wrong drag image/crash problem.

This is because gDragImageChanged is never cleared unless nsNativeDragTarget::DragOver is called. Step 2 in the STR will end the drag session without firing a dragover event. Therefore the next drag session at step 3 will try to set the outdated drag image when it fires a dragover event. I guess it causes a wrong drag image/crash problem.

That issue causes the incorrect feedback image, which is easy to fix, but it doesn't relate to the crash. The crash will occur even when updateDragImage is never called.

The crash only occurs if you drag the tab upwards fast enough such that the source feedback image is applied (by IDragSourceHelper::InitializeFromBitmap) but no drag events occur over the Firefox window. This is fairly easy to do with tabs since they sit in the titlebar. For the second drag (step 3), the drag helper seems to get confused by the coordinates of the drag. Often it crashes only when moving the mouse past a certain point. If I drag onto the Firefox window from the right or bottom side, the feedback image appears way off in the wrong position. In fact, if I drag over the scrollbar near the corner, the feedback image flies around the bottom of the screen repeatedly despite not moving the mouse. I confirmed that the coordinates in the point passed to DragOver are correct.

This is possibly some Windows 10 specific bug that may need to be worked around.

(In reply to Gabriele Svelto [:gsvelto] from comment #49)

(In reply to kbuxton from comment #48)

I finally got annoyed enough at this happening just often enough to search for info about it today. The problem seems to be the same as others are experiencing, but I'll mention the most frustrating point... It's frequently that I'm not even trying to drop the file on firefox, just crossing over it on my screen. I'll make the error reporting change in #27 to see if I can get more info for you.

Windows 10, 2 monitors. Latest non-beta version of FF.

Firefox 80 should generate a crash report for this crash even w/o the changes from comment 27. Did it generate one when it happened? Can you point us to it? I am currently on vacation but will look into this when I come back.

I finally had this happen again and have a crash report. It looks like progress has been made on diagnosing, but I'll send anyhow

Thanks for the crash report Kristin, I've analyzed it and the stack trace is identical to comment 35 so it's definitely this bug.

I think we need to up the priority on this. The volume on Socorro appears relatively low, we can estimate no more than ~400 crashes per day. However it seems like Windows Error Reporting is catching a lot of these crashes and not making them go through our crash reporter. WER Microsoft dashboards show this is causing ~9k crashes per day which would put it in the top 50 Windows crashes.

Neil, are you able to look into this bug right now? Or are you flooded with higher priority work? Note this seems to be a hidden topcrasher.

Flags: needinfo?(enndeakin)
Keywords: crash

I am seeing this crash more frequently lately. Sometimes multiple times per day. It's to the point that I'm starting to avoid using drag-n-drop because I never know if it's going to kill all my open windows (maybe related? I have 13 windows open, each with 5 to 10 tabs, but most are not loaded/suspended).

On FF version 82.0.2 64-bit, Windows 10 1909

I can send the crash dump file if that is still needed.

Hi,

I'm on Windows 10, Firefox 82.0.3 (64-bit) and I also see this crash often.

Not sure it might be related, but it has happened to me multiple time when I drag and dropped into firefox, but passed over a window that was accepting drag-n-drop (like Discord). But I'm not able to reproduce.

Let me know if I can send any relevant info.

Been having this issue as well,
Let me know if there's anything I can contribute as far as logs/dumps.

  • Multiple Monitors
  • Frequently use Multi-Desktop
  • Each time I have the issue, I reopen firefox and reattempt with 100% success rate so far on freshly reopened firefox (probably 5+ events)

We're able to reproduce this, but it's annoying to debug because it involves UI interaction.

Assignee: enndeakin → bobowencode
Flags: needinfo?(enndeakin)

Hi everyone,

I'm having this issue everyday for months. I drag and drop maybe 40-50 files a day and one of them always causes this crash. No reports in about:crashes. I feel really uncomfortable while drag&dropping anything since I might lose progress/data related to my work. Constantly checking and saving everything in different tabs has become a burden.

I do think this should be high priority because the crash reporter won't appear and most of the users might just be ignoring it. Please let me know if there is any input that I can share.

I've managed to capture this in a Time Travel Trace and am investigating.

At first glance this looks to be a coordinate miscalculation inside the Windows dragdrop libraries. From what I'm seeing, I believe the crash can be avoided as long as the first point of contact between the drag and Firefox is as far as possible to the right side of the rightmost screen. I'd be interested in hearing from folks who hit this regularly whether that's your experience as well.

Assignee: bobowencode → dmajor

Bob has been investigating this at the same time (apologies for stomping on the bug!) and it's likely that the miscalculations stem from something on the Firefox side.

Assignee: dmajor → bobowencode

I'm getting this a lot (but inconsistently) when drag/dropping into Gmail. There's no crash reporter that pops up, Firefox just freezes for 1-2 seconds and then vanishes. It doesn't even require a mouse-up, just hovering with the mouse button down is enough.

Note: one thing that's also happening to me and seems new relative to other comments is that when I'm drag/dropping from my synced Google Drive, it's not just crashing but also deleting the file. (And, worse still, Google Drive is not keeping any version of it --- so it's caused me real data loss in some cases!)

This is an attempt clean up any stale information to try and solve crashes later
in the drag in nsNativeDragTarget::DragOver.

Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/autoland/rev/47e600a37e25 Call IDropTargetHelper::DragLeave before IDropTargetHelper::DragEnter. r=dmajor,NeilDeakin

https://hg.mozilla.org/mozilla-central/rev/47e600a37e25

Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 4 years ago
status-firefox86: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

(In reply to voracity from comment #83)

I'm getting this a lot (but inconsistently) when drag/dropping into Gmail. There's no crash reporter that pops up, Firefox just freezes for 1-2 seconds and then vanishes. It doesn't even require a mouse-up, just hovering with the mouse button down is enough.

Note: one thing that's also happening to me and seems new relative to other comments is that when I'm drag/dropping from my synced Google Drive, it's not just crashing but also deleting the file. (And, worse still, Google Drive is not keeping any version of it --- so it's caused me real data loss in some cases!)

Thanks for the information and sorry that this has caused actual data loss.
The attempted fix is in Nightly now, so it would be good to know if you can confirm it fixes your issue as well.

Flags: needinfo?(subs)

Should we uplift to beta and/or esr78?

Flags: needinfo?(bobowencode)

(In reply to Julien Cristau [:jcristau] from comment #89)

Should we uplift to beta and/or esr78?

I haven't found the root cause, just using DragLeave to clean-up again before the new DragEnter.
This fixes the STR we have and is hopefully safe, but it makes me a little nervous to ask for uplift.
Probably best to let it roll out normally to give the maximum time in Beta.

Assuming we don't see issues in Beta, I think it would be worth uplifting to ESR at that point as the next ESR will still be several months out.

Flags: needinfo?(bobowencode)

gsvelto - this potential fix has been in Nightly for 2 weeks now, I wonder if you can see any impact on the WER figures for this crash on Nightly (assuming you can see this level of detail).

Flags: needinfo?(gsvelto)

There is a Firefox nightly component in Microsoft's dashboard and there are no crashes past the 21st of December. However the dashboard goes back only a month and there are only 10 crashes in total so it's hard to be sure. It is encouraging though, I can keep an eye on the dashboard.

Flags: needinfo?(gsvelto)

Removing the second signature since we had no crashes under it in 6 months.

Crash Signature: [@ CDragDropHelper::MakeRectOpaqueOnBitmap ] [@ shell32.dll@0x240ea7 ] → [@ CDragDropHelper::MakeRectOpaqueOnBitmap]

Still no new crashes on nightly, both on Socorro and in the WER dashboards. Seems like the issue is fixed for good.

Comment on attachment 9193933 [details]
Bug 1465513: Call IDropTargetHelper::DragLeave before IDropTargetHelper::DragEnter. r=dmajor!

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a whole browser crash the extent of which has been hidden for a long time because our crash reporter normally doesn't catch it. We see quite high numbers in the Windows Error Reporting information.
  • User impact if declined: Dragging and dropping onto Firefox will continue to be affected by this crash.
  • Fix Landed on Version: 86
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a very simple patch that calls IDropTargetHelper::DragLeave before we call IDropTargetHelper::DragEnter, to make sure old drag resource references have been cleaned up.
  • String or UUID changes made by this patch: None
Attachment #9193933 - Flags: approval-mozilla-esr78?

Comment on attachment 9193933 [details]
Bug 1465513: Call IDropTargetHelper::DragLeave before IDropTargetHelper::DragEnter. r=dmajor!

approved for 78.8esr

Attachment #9193933 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+

I see this says it's fixed in FF86. I'm on FF86 and literally just had Firefox crash. I wasn't even dragging a file to Firefox. I just happened to mouse over the Firefox window while getting to another program entirely. There's nothing in about:crashes for this. Firefox just outright shuts down without any warning.

(In reply to ross from comment #98)

I see this says it's fixed in FF86. I'm on FF86 and literally just had Firefox crash. I wasn't even dragging a file to Firefox. I just happened to mouse over the Firefox window while getting to another program entirely. There's nothing in about:crashes for this. Firefox just outright shuts down without any warning.

This is probably a different crash. Open a new bug and needinfo me and I'll help you diagnose it.

Removing old needinfo asking for test of fix in Nightly as it landed over 4 years ago.

Flags: needinfo?(subs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: