Closed Bug 815678 Opened 9 years ago Closed 9 years ago
Downloads Panel changes width when scanning completed download
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20.0 Firefox/20.0 Build ID: 20121127030907 On the latest Nightly the width of the Downloads panel changes the first time a download is ever made through the panel. This behavior is not encountered on Ubuntu 12.04 and Mac OS X 10.7. This is only reproducible on Windows. Reproducible: always Steps to reproduce: 1. Launch Firefox with a new profile. 2. Navigate to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and download the any exe file 3. Observe the Downloads Panel until the download is complete. Expected results: The width of the downloads panel is the same until the download is completed. Actual results: The width of the downloads panel changes back and forth in the moment of the completion. Please see the screencast for more details: http://screencast.com/t/7lcjPWEqv
This shouldn't really happen :(
9 years ago
Assignee: nobody → mconley
Simona: Thanks so much for catching this - and especially for the screencast. I was able to go through each frame and see the cause of the panel resize. The cause seems to be when we're in the "scanning" state, the download item button/icon is collapsed. For the toolkit downloads manager, we also hide the icons when scanning, but the effect is not jarring because the window does not automatically resize. I'll see if I can rig a blank placeholder for the button / icon so that we don't resize. Thanks again Simona! -Mike
9 years ago
Summary: Downloads Panel changes width before the completion of the download → Downloads Panel changes width when scanning completed download
Fixes the issue for winstripe.
Updating pinstripe to account for downloadButtonContainer.
Attachment #685784 - Attachment is obsolete: true
This takes care of gnomestripe too.
Attachment #685800 - Attachment is obsolete: true
Comment on attachment 685806 [details] [diff] [review] Patch v1 So this patch puts the download item buttons into a XUL box that has a min-height and min-width set on it. Not sure if we need the downloadButtonContainer stylings on gnomestripe and pinstripe, since I've never seen virus scanning through Firefox on either of those platforms, but I went for it anyway. Also, since I added the new container, I had to relax some of the CSS rules that assumed that the buttons were directly beneath the downloaditem.
What I dislike is the hardcoded values, basically any change in the buttons css (even in toolkit) will break this. Mike is going to try a solution with a <stack> and visibility: hidden.
The stack and toggling visibility: hidden seems to do the trick! This gets rid of those hard-coded width values, which is awesome. Testing on Windows next, and then I'll r?.
Comment on attachment 686127 [details] [diff] [review] Patch v2 This fixes the issue on Windows as well. I feel a lot better about this approach.
Attachment #686127 - Flags: review?(mak77)
Comment on attachment 686127 [details] [diff] [review] Patch v2 Review of attachment 686127 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/components/downloads/content/downloads.css @@ +68,5 @@ > display: none; > } > > +/*** Visibility of download item icons, and the controls inside the downloads > + indicator ***/ "download item icons" is confusing, I thought of the icon for each download... let's use "buttons" instead of "icons". Actually "Visibility of download buttons and indicator controls" is enough imo.
Attachment #686127 - Flags: review?(mak77) → review+
Thanks Marco! Comment fixed.
Attachment #686127 - Attachment is obsolete: true
Landed on mozilla-inbound as https://hg.mozilla.org/integration/mozilla-inbound/rev/d263e80907f9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Verified as fixed on the latest Nightly - the panel doesn't change width when scanning completed download. Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20121203 Firefox/20.0 Build ID: 20121203030801
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.