User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36 Edge/14.14341 Steps to reproduce: 1. Hit Ctrl+O to open the ‘Open File’ dialog 2. Try to drag a file out of that dialog to the desktop Actual results: The copy/move doesn’t complete when you let go of the mouse button. Need to get out of drag mode using ‘Esc’. If you drag it very quickly, it does work. Expected results: File can be copied/moved using drag & drop We’ve debugged from the Windows side and found that the thread is stuck waiting for messages as if the mouse was never released. There are a few potential theories/suggestions such as checking if there is a message filter or running the open dialog in the FF broker process.
I can reproduce it sometimes in Fx47b2 on Win10.
Status: UNCONFIRMED → NEW
Component: Untriaged → Widget: Win32
Ever confirmed: true
OS: Unspecified → Windows
Product: Firefox → Core
Hardware: Unspecified → All
Also reproduce in Nightly 2016-05-01 & 20141002093155 (35.0a1) & ... https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac376a4e8174&tochange=c8055a00235d Suspect: bug 992415.
Has Regression Range: --- → yes
Has STR: --- → yes
Note that it can reproduce either e10s on/off.
3 years ago
E10S/win32 regression, so over to Jim. From bug 992415 comment 1: > I looked at how HTMLInputElement handles this. Hmm, this makes me wonder if there's a similar problem involving that code path?
Flags: needinfo?(dolske) → needinfo?(jmathies)
This has been around since at least 35. May have been caused by some e10s related work back in 2014. I can reproduce in current release 46.
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
Wontfix for 46 and 47 as we are late in the beta cycle for 47. How common do we think this problem is? I'm not sure of the user impact here.
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
Dragging a file from the *file-open* dialog to the desktop, which essentially moves the file, isn't a common operation. This would be users who are opening a file *picker*, and then instead of picking a file, they are moving a file. It looks like Jim has marked it as a P1 but if this is the only way users see the bug then I would say it is a low impact bug.
3 years ago
platform-rel: --- → ?
Whiteboard: tpi:+ → tpi:+ [platform-rel-Microsoft][platform-rel-Windows]
status-firefox48: affected → fix-optional
status-firefox49: affected → fix-optional
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.