1. Download any file 2. Open the doorhanger download panel menu 3. Double click the folder icon fast The file browser will open as expected, but it will also start a new download of the file from the local directory.

I cannot repo this...

I will try to get a video when I get the time.

Ok, CamStudio won't play nice, but I've mucked around with it some more. Basically if you click fast on the folder icon, the menu item (the download in the panel) sometimes get stuck to your pointer, and when you focus again on the browser window, it'll think you dragged and dropped the file (starting a new download from the local directory) It's not a mouse issue, I've tried it with two different ones. I'm not sure it's a very serious issue either, but it's something that's introduced with the new download panel, and it should at least be noted.

I think that we should need to fix this bug until ship to release new DL manager. Old toolkit DL manager need double-clicking to open a downloaded files. So this difference will user confusing. And Its confusing will be security risk. I set up the malefic attacking scenario: 1. A attacking site make a file having malware is downloaded. This process is not needed by user. 2. User will think that "What is this downloaded file?", he may click it with single clicking. Thus its malware will be opened. 3. As the result, malefic attacking will success... So this is a potential security risk. Firefox user recognize that it need to open with double-clicking. But the current behavior breaks this recognition. Therefore this is a *potential*, but we cannot overlook it. This is so bad that the double-clicking behavior of toolkit DL manager is common behavior in users.

> This is so bad that the double-clicking behavior of toolkit DL manager is common behavior in users. Sorry. I sent draft comment. This sentence means, "This is so bad *because* the double-clicking behavior of toolkit DL manager is common behavior in users.".

I agree that any action on other than the download (open folder in this case) should not open it. But what you are reporting about single and double clicking doesn't look related to this report... Btw the OS in almost all cases asks confirmation to the user before opening executables downloaded from the web.

(In reply to Marco Bonardo [:mak] from comment #6) > I agree that any action on other than the download (open folder in this > case) should not open it. > But what you are reporting about single and double clicking doesn't look > related to this report... Btw the OS in almost all cases asks confirmation > to the user before opening executables downloaded from the web. Oops.... I have misread the summary of this bug. I apologize that I wrote the comment which is not related to this. Thank you for your indication. I filed the new bug about my thought: bug 806076.

I restore statuses about this bug. Sorry. (In reply to Marco Bonardo [:mak] from comment #6) > Btw the OS in almost all cases asks confirmation > to the user before opening executables downloaded from the web. Its behavior is not implemented on all platform. Also, non-executable files be able to become malware (Image file can attack to a vulnerability of image editing apps, for example, photoshop.).

well, regardless we should fix the open download folder button to stop the click events propagation.

David: I'm not having any luck reproducing this. Are you still experiencing this on Nightly? -Mike

Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0 BuidID: 20121105030642 I couldn't reproduce this either on Windows 7 32-bit. I will try again later on Windows 7 64-bit and post the results.

Unblocking and moving status to unconfirmed until we have proper steps to reproduce the problem.

Could not reproduce this on Windows 7 64-bit either. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121213 Firefox/20.0 Build ID: 20121213030751

I cannot reproduce this bug using the latest Aurora and Windows 7 64 bit. As it hasn't been reproducible for over 3 months and with several people trying, I'm resolving it incomplete.

Thanks Gabriela. I agree with this. If anyone is still able to reproduce this with an up to date Firefox version, please reopen this bug and provide more specific details (including steps to reproduce).

So shouldn't this bug be marked as WORKSFORME instead of INVALID.

(In reply to Virtual_ManPL [:Virtual] from comment #16) > So shouldn't this bug be marked as WORKSFORME instead of INVALID. It's not invalid, it's incomplete.

(In reply to Virtual_ManPL [:Virtual] from comment #16) > So shouldn't this bug be marked as WORKSFORME instead of INCOMPLETE. I had in mind this.

(In reply to Virtual_ManPL [:Virtual] from comment #18) > (In reply to Virtual_ManPL [:Virtual] from comment #16) > > So shouldn't this bug be marked as WORKSFORME instead of INCOMPLETE. > I had in mind this. No, let me explain. INCOMPLETE is used when closing a bug we were never able to confirm. WORKSFORME is used when closing a bug we were once able to confirm. I suppose you could argue for WORKSFORME based on comment 9 but comment 12 basically negates that. I still believe this to be INCOMPLETE under those circumstances. That said, this bug is not the appropriate place to debate the use cases of various bug status. If you'd like to debate this further, feel free to email me. Thank you