Open Bug 1345813 Opened 3 years ago Updated 2 years ago
Dropping a local file over a html page is not allowed
[Affected versions]: - Firefox 53 Beta 1 - Aurora 54.0a2 - Nightly 55.0a1 [Affected platforms]: - All [Steps to reproduce]: 1. Navigate to CNN.com: http://edition.cnn.com/ 2. Drag a local file and drop it on the URL bar from step 1 [Expected result]: - Dragging is allowed, the path of the local file should be copied in the URL bar [Actual result]: - Dragging is not allowed - red circle is displayed. [Regression range]: Last good revision: bad312aefb42982f492ad2cf36f4c6c3d698f4f7 First bad revision: c41dab3b9a7230a377d68d30244bd201258ce10d Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bad312aefb42982f492ad2cf36f4c6c3d698f4f7&tochange=c41dab3b9a7230a377d68d30244bd201258ce10d [Additional notes]: - not reproducible on Firefox 52.
I bisected this and it was caused by bug 1229426. Not sure if it was an intentional change.
one of the checks in _getDroppableItem is likely failing.
Has Regression Range: --- → yes
Has STR: --- → yes
Priority: -- → P3
Console says: Security Error: Content at http://edition.cnn.com/ may not load or link to file:///C:/... This makes sense. We should probably avoid the error if the drag originates from Windows and/or doesn't come from inside the browser's content. That said, you can still easily open the file by opening a new tab first, or dragging it to the tab bar, or using open file (accel-o) so I don't think this is a serious regression that needs to block 53 shipping.
gijs: what's the way forward on this? will this be fixed in 55 (by who?), and how far should we uplift? While there's a workaround, it's not clear that a user who uses this workflow (drop on address bar) would find it. Thanks
(In reply to Randell Jesup [:jesup] from comment #4) > gijs: what's the way forward on this? will this be fixed in 55 (by who?), At the moment, nobody is assigned to this and it's not a priority (P3). So as it stands, no. > and how far should we uplift? While there's a workaround, it's not clear > that a user who uses this workflow (drop on address bar) would find it. Why not? Why wouldn't they open a new tab, anyway - why would you drop the file on the url bar of a tab that already has a http webpage loaded? Dropping in the tabstrip, or dropping in the URL bar on a tab that doesn't have a http URL loaded, all works.
To expand a little: on the benefit side, I don't think this is actually a common usage pattern, and on the cost side, fixing this properly is Hard if we don't want to regress security guarantees (i.e. if a webpage links to a file URL you should not be able to drag that to the URL bar to open it) - my experience is that distinguishing where drags come from is already a problem, especially on e10s, and so trying to figure out if the drag came from outside the app seems fraught with issues.
Let's try to get this fixed and uplift to 54, or ride the trains
Given comment 5, I'm going to declare this fix-optional for 54 and 55, and let the appropriate team decide what they want to do with this bug when they do backlog triage.
(In reply to Simona B [:simonab ] from comment #0) > [Actual result]: > - Dragging is not allowed - red circle is displayed. Please be aware that on Linux (Ubuntu 16.04) and Mac (OSX 10.12) users might get confused since you don't get the same behavior as in Windows, where while you are hovering with the drag on the address bar, it shows that the drop is blocked.
You need to log in before you can comment on or make changes to this bug.