Closed Bug 1399490 Opened 7 years ago Closed 7 years ago

Downloads button is inaccessible after removing it from the toolbar and restarting Firefox

Categories

(Firefox :: Toolbars and Customization, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 57
Iteration:
57.3 - Sep 19
Tracking Status
firefox57 --- verified

People

(Reporter: nhnt11, Assigned: Gijs)

References

Details

(Whiteboard: [reserve-photon-structure])

Attachments

(1 file)

On a new profile:

1. Start a download (the button appears in the toolbar). I could reproduce the bug with the next few steps whether I waited for the download to complete or not.
2. Right click the Downloads button and remove it from the toolbar. It is now accessible from customize mode.
3. Restart Firefox. It is now gone from customize mode, and does not automatically appear either (though the latter is expected).
Blocks: 1397447
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 57.3 - Sep 19
Flags: qe-verify+
Priority: -- → P1
QA Contact: gwimberly
Whiteboard: [reserve-photon-structure]
Comment on attachment 8907645 [details]
Bug 1399490 - fix unhiding the downloads button in customize mode if it was moved to the palette,

https://reviewboard.mozilla.org/r/179316/#review184456

::: browser/components/downloads/content/indicator.js:326
(Diff revision 1)
> -        if (this._initialized) {
> +        // We need to re-check for the placeholder because it might have
> +        // disappeared since then.

I needed to add this because otherwise the automated test hit:

```
96 INFO TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_downloads_autohide.js | uncaught exception - TypeError: this.indicator is null at _refreshAttention@chrome://browser/content/downloads/indicator.js:552:7
set percentComplete@chrome://browser/content/downloads/indicator.js:508:7
_updateView@resource:///modules/DownloadsCommon.jsm:1209:5
refreshView@resource:///modules/DownloadsCommon.jsm:939:5
_ensureOperational/<@chrome://browser/content/downloads/indicator.js:325:11
ensureOverlayLoaded@chrome://browser/content/downloads/downloads.js:614:7
processPendingRequests@chrome://browser/content/downloads/downloads.js:649:7
ensureOverlayLoaded/<@chrome://browser/content/downloads/downloads.js:630:7
```

but it seems clear this is a pre-existing bug where there's a race condition of the overlay being loaded and the button being moved to the palette. Oh well.
Comment on attachment 8907645 [details]
Bug 1399490 - fix unhiding the downloads button in customize mode if it was moved to the palette,

https://reviewboard.mozilla.org/r/179316/#review185010

Thanks!

::: browser/components/downloads/test/browser/browser_downloads_autohide.js:277
(Diff revision 1)
> +  let paletteButton = otherWin.gNavToolbox.palette.querySelector("#downloads-button");
> +  ok(paletteButton, "Button should exist in the palette");
> +  if (paletteButton) {
> +    ok(paletteButton.hidden, "Button will still have the hidden attribute");
> +    await promiseCustomizeStart(otherWin);
> +    ok(!paletteButton.hidden,

Should we also check that the button exists in the document?
Attachment #8907645 - Flags: review?(nhnt11) → review+
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/c1744a3f7a8e
fix unhiding the downloads button in customize mode if it was moved to the palette, r=nhnt11
https://hg.mozilla.org/mozilla-central/rev/c1744a3f7a8e
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
I have reproduce this issue using an affected Nightly build from 2017-09-13.

Verified fixed on 57.0b7 (20171009192146) under Mac OS X 10.11, W10 x64 and Ubuntu 16.04 x64.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.