Dragging a file from Firefox's open file dialog to the Windows desktop doesn't work

NEW
Unassigned

Status

()

P1
normal
Rank:
75
2 years ago
5 months ago

People

(Reporter: cmorris, Unassigned)

Tracking

({regression})

46 Branch
All
Windows
regression
Points:
---

Firefox Tracking Flags

(e10s-, platform-rel +, firefox46 wontfix, firefox47 wontfix, firefox48 fix-optional, firefox49 fix-optional)

Details

(Whiteboard: tpi:+ [platform-rel-Microsoft][platform-rel-Windows])

Attachments

(1 obsolete attachment)

(Reporter)

Description

2 years ago
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.

Comment 1

2 years ago
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

Comment 2

2 years ago
Also reproduce in Nightly 2016-05-01 & 20141002093155 (35.0a1) & ...

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac376a4e8174&tochange=c8055a00235d

Suspect: bug 992415.
Blocks: 992415
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression

Updated

2 years ago
tracking-e10s: --- → ?

Comment 3

2 years ago
Note that it can reproduce either e10s on/off.
Flags: needinfo?(pdolanjski)
Flags: needinfo?(dolske)
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)

Comment 5

2 years ago
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
Flags: needinfo?(pdolanjski)
Flags: needinfo?(jmathies)

Updated

2 years ago
Priority: -- → P1
Whiteboard: tpi:+

Updated

2 years ago
tracking-e10s: ? → -
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
Flags: needinfo?(jaws)
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.
Flags: needinfo?(jaws)
Comment hidden (typo)
Comment hidden (typo)

Updated

2 years ago
Attachment #8756973 - Attachment is obsolete: true
Attachment #8756973 - Flags: review?(jmuizelaar)
Attachment #8756973 - Flags: review?(bgirard)
platform-rel: --- → ?
Whiteboard: tpi:+ → tpi:+ [platform-rel-Microsoft][platform-rel-Windows]
status-firefox48: affected → fix-optional
status-firefox49: affected → fix-optional

Updated

2 years ago
platform-rel: ? → +

Updated

2 years ago
Priority: P1 → P2

Updated

2 years ago
Rank: 75

Updated

5 months ago
Priority: P2 → P1
You need to log in before you can comment on or make changes to this bug.