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

VERIFIED FIXED in Firefox 57

Status

()

defect
P1
normal
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: nhnt11, Assigned: Gijs)

Tracking

Trunk
Firefox 57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 verified)

Details

(Whiteboard: [reserve-photon-structure])

Attachments

(1 attachment)

Reporter

Description

2 years ago
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).
Assignee

Updated

2 years ago
Blocks: 1397447
Assignee

Updated

2 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 57.3 - Sep 19
Flags: qe-verify+
Priority: -- → P1
QA Contact: gwimberly
Whiteboard: [reserve-photon-structure]
Assignee

Comment 2

2 years ago
mozreview-review
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.
Reporter

Comment 3

2 years ago
mozreview-review
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+
Comment hidden (mozreview-request)

Comment 5

2 years ago
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: 2 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.