Closed Bug 978291 Opened 6 years ago Closed 6 years ago
about:downloads can't handle drag events if downloads list is empty
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140212131424 Steps to reproduce: Wanted to drag'n'drop an image to the downloads list displayed in an addon via `about:addons` page, in order to initiate the download. The downloads list was empty. Actual results: Nothing happened. Expected results: A file download should have started.
I've found this issue inside the All-in-One Sidebar addon, and it lead to an issue in `about:downloads` page in the core. (tested with Firefox 27 and AiOS 0.7.21) https://github.com/AddonLab/AiOS/issues/31 When you try to drag'n'drop some files into the "downloads" panel of AiOS, it works and files are correctly downloaded. However this only works if there were already some files on the downloads list. If there were none, the panel displays "There are no downloads" and you can't drag'n'drop anything over there to initiate a new download. AiOS uses the `about:downloads` URI to display this panel. When you open `about:downloads` in Firefox and inspect it with Firebug when there are some downloads, you'll see that each of the downloads is an item of a <richlistbox>. The "There are no downloads" text is a <description id="downloadsListEmptyDescription"> node. Related CSS: https://github.com/mozilla/gecko-dev/blob/master/browser/components/downloads/content/contentAreaDownloadsView.css tells that if there are some downloads, the latter node is hidden, otherwise, if there are none, it is displayed. In the latter case, due to the fact that <richlistbox> has no children the #downloadsListEmptyDescription takes 100% width and height. Those two nodes are siblings and only <richlistbox> has ondrag/ondrop handlers. Hence if the downloads list is empty, there's no element capable of intercepting drag/drop events.
Here's a commit that might solve this issue https://github.com/jakub-g/gecko-dev/commit/cb2f477ef56264c2a4f10e3571f16a0886c07bd9 I haven't built/tested this but I think the fix should go somewhere along those lines.
#downloadsListEmptyDescription should not be the target of mouse events
Assignee: nobody → alice0775
Comment on attachment 8384080 [details] [diff] [review] bug978291.patch I may look at this patch
Attachment #8384080 - Flags: review?(mak77)
Comment on attachment 8384080 [details] [diff] [review] bug978291.patch conceptually it's correct, though I'd prefer a patch setting mousethrough="always" on downloadsListEmptyDescription
Attachment #8384080 - Flags: review?(mak77) → feedback+
Are you willing to provide such a patch by chance?
#downloadsListEmptyDescription will not receive any mouse events
Attachment #8384080 - Attachment is obsolete: true
Comment on attachment 8387644 [details] [diff] [review] bug978291.patch_v2 Review of attachment 8387644 [details] [diff] [review]: ----------------------------------------------------------------- yep, thanks please add a checkin comment and checkin-needed!
Attachment #8387644 - Flags: review+
added checkin comment to the attachment 8387644 [details] [diff] [review]
Attachment #8387644 - Attachment is obsolete: true
Attachment #8387678 - Attachment is patch: true
Assignee: nobody → alice0775
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Verified the fix with today's Nightly 30.0a1 (2014-03-08). Thanks to everyone involved for quick resolution!
You need to log in before you can comment on or make changes to this bug.