Closed Bug 978291 Opened 10 years ago Closed 10 years ago

about:downloads can't handle drag events if downloads list is empty

Categories

(Firefox :: Downloads Panel, defect)

27 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox27 --- affected
firefox28 --- affected
firefox29 --- affected
firefox30 --- verified

People

(Reporter: jakub.g.opensource, Assigned: alice0775)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
Component: Untriaged → Downloads Panel
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.
Attached patch bug978291.patch (obsolete) — Splinter Review
#downloadsListEmptyDescription should not be the target of mouse events
Assignee: nobody → alice0775
Assignee: alice0775 → nobody
Blocks: 824265
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Flags: needinfo?(alice0775)
Attached patch bug978291.patch_v2 (obsolete) — Splinter Review
#downloadsListEmptyDescription will not receive any mouse events
Attachment #8384080 - Attachment is obsolete: true
Flags: needinfo?(alice0775)
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
Keywords: checkin-needed
Attachment #8387678 - Attachment is patch: true
Assignee: nobody → alice0775
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/29154076b5c0
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 30
Verified the fix with today's Nightly 30.0a1 (2014-03-08).

Thanks to everyone involved for quick resolution!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: