1406906 - Downloads: "Go to Downloads Page" button is not working after restart

Status: NEW

(Toolkit :: Downloads API, defect, P3)

Description

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID:20171008220130

[Affected versions]:
Nightly 58.0a1

[Affected platforms]:
Windows 10 x64, Mac OS X 10.12

[Steps to reproduce]:
1.Launch Nightly 58.0a1 with a new profile
2.Download a file (e.g. http://archive.mozilla.org/pub/firefox/nightly/2017/10/2017-10-02-10-01-34-mozilla-central/)
3.Restart Firefox
4.Go to Menu->Library-> Downloads list
5.Right-click on the downloaded file
5.Click "Go To Download Page"

[Expected result]:
Download page should be opened in a new tab

[Actual result]:
Nothing happens

[Note]:
The issue is not reproducible before restart

Comment 1

[:Paolo Amadini]

This may be a combination of bug 838131 and bug 1377112.

Comment 2

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello,

This issue is now present without going trough step 3(restarting Firefox).

Clicking the "Go to Download page" does nothing and returns the following error in the Browser Console:

" An error occurred executing the downloadsCmd_openReferrer command: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: chrome://global/content/contentAreaUtils.js :: makeURI :: line 920" data: no] "

Comment 3

[Marco Bonardo [:mak]]

Apparently the menuitem should be disabled, not all the downloads have a referrer, I debugged into DownloadsSubview.updateContextMenu() it calls into DownloadsviewUI.isCommandEnabled() that returns false for "downloadsCmd_openReferrer". We set disabled = true on the menuitem, but that apparently doesn't have any effect.
Setting the "disabled" attribute instead works properly, that seems to indicate a problem with the binding not being applied...

Maybe it's related to the recent XBL removal work, it would be useful to find a regression range for this.

Comment 4

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello Marco,

I have narrowed down the regression range to 1 day from [2017-01-20, 2017-01-21] and got the following regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80eac484366ad881c6a10bf81e8d9b8f7a676c75&tochange=487a4e43eb9d1f04a5d8e3dd183fe38dbe105e1f

I tried to narrow it down even more but I get errors and skipped builds.
From the pushlog provided above, it would seem that the culprit that causes this issue would be Bug 1324571.

Hope it helps!

Comment 5

[Marco Bonardo [:mak]]

That regression range seems to be valid for bug 1377112, but I doubt it's the same bug tracked here... This bug is for the Library panel, not the Library window. Maybe that's the confusing part?