[Affected versions]: - Firefox 54.0.1 RC - Firefox 55.0b5 - latest Nightly 56.0a1 [Affected platforms]: - Windows 10 64bit - macOS 10.12.5 - Ubuntu 16.04 32bit/64bit [Steps to reproduce]: 1. Start Firefox 2. Visit the following website: http://www.pdf995.com/samples/pdf.pdf 3. Download the pdf 4. Open Library and right click the pdf 5. Notice "Go to download page" [Expected result]: - "Go to download page" is disabled [Actual result]: - Go to download page option is enabled and it does nothing when clicking it. [Regression range]: - This is not a recent regression but it is a regression nonetheless. Last good revision: 3d6d5a48deaf7c146b093ae129a0cb75c4334c0c First bad revision: 2e438048aa9d6d90b4d0c96a506d7ef01a1053cc Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3d6d5a48deaf7c146b093ae129a0cb75c4334c0c&tochange=2e438048aa9d6d90b4d0c96a506d7ef01a1053cc Probably caused by: c8b01174d713 Pavan — Bug 1324571 - Use cases of some multi-selection commands in Downloads Library not clear. r=mak
Well, This is weird, but why should "Go to download page" be disabled? I don't know why nothing is happening btw. But according to the patch on Bug 1324571, "Go to download page" is enabled if a single item is selected, else disabled.
(In reply to Pavan Karthik [:matrixisreal] from comment #1) > Well, This is weird, but why should "Go to download page" be disabled? > I don't know why nothing is happening btw. > But according to the patch on Bug 1324571, "Go to download page" is enabled > if a single item is selected, else disabled. Well it's disabled in Download Panel for the same file, I guess it shouldn't be disabled at all then. I also saw this with sample test files from this website https://www.thinkbroadband.com/download
I guess that we may not have a referrer, the downloads panel checks this.download.source.referrer, while the Places view only checks the selection number. It's not given that a download has a referrer. I see what's the problem with bug 1324571, before the "downloadsCmd_openReferrer" command was handled by the "default:" case, while now we handle it apart. For this specific command, we should probably return this._richlistbox.selectedItems.length != 1 ? false : this._richlistbox.selectedItems._shell.isCommandEnabled(aCommand) Pavan, would you have time to look into this?
it may be a good idea to assign this._richlistbox.selectedItems to a temp var to make the code more readable.
Not a recent regression. Mark 54 won't fix. Let's see if we can fix it in 55.
status-firefox54: affected → wontfix
Assignee: nobody → pavankarthikboddeda
Will, find time to work on this sometime this week!
status-firefox55: affected → wontfix
status-firefox56: affected → wontfix
You need to log in before you can comment on or make changes to this bug.