Regression: clicking "open containing folder" button in the downloads panel (and perhaps also about:downloads) also launches/opens the downloaded file
Categories
(Firefox :: Downloads Panel, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | unaffected |
firefox71 | + | verified |
People
(Reporter: Gijs, Assigned: ckerschb)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1582532 +++
From comment #2 on that bug:
STR
0. Associate ".zip" file to 7-zip etc..
Open http://ftp.mozilla.org/pub/firefox/nightly/2004/02/2004-02-10-08-trunk/MozillaFirebird-win32.zip
Save it.
Click the downloads button in NavBar after download finished.
Click Folder Icon at the right side of list item
Actual results:
File Explorer and zip associated application will open.
Expected Results:
Only File Explorer will open.
This is a regression from bug 1497200. The original bug 1582532 seems to be a separate issue.
Reporter | ||
Comment 1•5 years ago
|
||
[Tracking Requested - why for this release]:
This is a nightly regression.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Christoph, your patch in bug 1497200 seems to have caused this bug, could you have a look please? Thanks
Assignee | ||
Comment 3•5 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #2)
Christoph, your patch in bug 1497200 seems to have caused this bug, could you have a look please? Thanks
Yep, it's already assigned to me - I'll take care of it.
Just to add, the issue is only in the downloads panel. The Library Downloads branch and the about:download page both working as expected
Assignee | ||
Comment 6•5 years ago
|
||
Hi Gijs,
I think I figured what the problem is, the original code used an "oncommand" handler [0]. Within onDownLoadClick [1] the event does not get treated if it has the attribute "oncommand". Question is, how do we fix that? Can we somehow check if an "command" event listener was added using .addEventListener? Or is there a better approach?
I fiddled with the code for testing purposes and if that code [1] is not executed then it works as expected, we only open the file explorer.
Any suggestions?
[0] https://hg.mozilla.org/mozilla-central/rev/1572223bd5ec#l1.13
[1] https://searchfox.org/mozilla-central/rev/f372e8a46ef7659ef61be9938ec2a3ea34d343c6/browser/components/downloads/content/downloads.js#819
Reporter | ||
Comment 7•5 years ago
|
||
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #6)
Hi Gijs,
I think I figured what the problem is, the original code used an "oncommand" handler [0]. Within onDownLoadClick [1] the event does not get treated if it has the attribute "oncommand".
Gah. This is horrible. :-(
Question is, how do we fix that? Can we somehow check if an "command" event listener was added using .addEventListener? Or is there a better approach?
I'm pretty sure event.originalTarget.localName == "button"
should do the trick. Still ugly though. Might be worth adding a comment in the code that has the markup to indicate this could potentially be a problem if people changed the markup.
Other options involve also adding a click
handler on the button and calling stopPropagation() in there, but that might prevent the command
event being created, I'm not sure, and also wouldn't scale to trying to handle the command events more centrally if we wanted to avoid N handlers for N download items. That latter objection also applies to a third option, which would be to use the event listener service (Services.els.getListenerInfoFor
); to ask the DOM whether there's a "command" event listener registerd on the originalTarget
.
Reporter | ||
Comment 8•5 years ago
|
||
Also, it would be great if we could have tests for this, but I bet it's tricky to synthetically fire a "real" click event that demonstrates this problem...
Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/f1d5fcf421a4 Stop propagation of event. r=Gijs
Comment 11•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Reproduced the initial issue on Firefox 71.0a1 (2019-09-27).
Verified fixed on Windows 7 x64, Ubuntu 18.04 x64 and macOS 10.15 using Firefox 71 Beta 5 (buildID: 20191028110005).
Updated•2 years ago
|
Description
•