754389 - Downloads list can't intermittently be summoned.

Status: NEW

(Firefox :: Downloads Panel, defect)

Description

[M ODonnell]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120511030513

Steps to reproduce:

Allowed Nightly to update itself.


Actual results:

After a few invocations the Downloads list will no longer appear when summoned using either the widget near the upper right corner of the menu pick Tools->Downloads


Expected results:

Downloads list should appear when summoned and show status of previous and current downloads.

Comment 1

[M ODonnell]

Typo - should have read: "...near the upper right corner *or* the menu pick Tools->Downloads

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Downloads is supposed to open the full manager, not the panel.
I'm going to resolve this, but if you can reproduce it in current Nightly (that is, if it doesn't open the manager always), feel free to reopen.

Comment 3

[M ODonnell]

I'm just a civilian so I don't know the difference between the "panel" and the "full manager" but in any case it would be great if you could please just change this status back to OPEN as I am using Firefox Nightly version 19.0a1 (2012-10-19) and this bug is still readily reproducible.  Right now, for example, I downloaded a file and was then several times able to click on the little "Downloads" icon on the Navigation Toolbar, each time seeing the panel/manager/whatever widget produced as expected, until maybe the fourth or fifth time.  Now, although the icon shows its button-depressed mode each time I click it, no panel/manager/whatever widget appears.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

ok, so if you click quickly on the button sometimes it gets confused and doesn't open the panel.

Comment 5

[M ODonnell]

Clicking quickly may exacerbate the problem but I don't think it's a requirement for reproduction, it's more that the feature seems to work as expected the first few times it's used and then fail from that point on until Firefox is restarted.  FWIW, system info:

 Linux 3.5.2 SMP i686 Debian GNU/Linux wheezy/sid

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

any add-ons to report? Those may be interacting with popupshowing events.

Comment 7

[M ODonnell]

Yes, I do have (quite a few) add-ons and will provide a list shortly, but meanwhile have discovered something else of note: my work habits have me routinely operating with multiple browser windows open, each with multiple tabs. For example, right now I have 6 windows open, but only one exhibits the b0rken behavior in question, with the "Downloads" icon/button on the Navigation toolbar correctly summoning the panel as expected in all the other windows.  This is reproducible; I have restarted the browser and when the failure finally occurs it's just in the one browser window where it's initially seen and with the others continuing to behave correctly.

Comment 8

[M ODonnell]

OK, I lied - I don't plan to supply my list of add-ons because it turns out they're irrelevant.  On my Linux box I renamed my ~/.mozilla directory (effectively hiding it from Firefox) and then restarted what could now be described as a "virgin" Firefox since it was an entirely out-of-the-box version with no local modifications.  To ensure that, I viewed the about:support page and clicked the button that forced a config Reset and a browser restart.  I was then able to reproduce the bug in question thus:

 - opened 4 browser windows
 - opened a bunch of tabs in each window
 - pointed each tab at a different innocuous page
 - in one page, right clicked a tab and selected Reload all tabs
 - while browser was busy reloading those pages, clicked the "Downloads" icon button on the Navigation toolbar.

...with the result that it worked the first few times and then failed as described.  The feature in question continued to work in the other pages.

Comment 9

[M ODonnell]

This (tidied up a bit) is what about:support has to say:

Application Basics
      Name / Firefox
      Version / 19.0a1
      User Agent / Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0
Extensions
      Name / Version / Enabled / ID
      [ none ]
Important Modified Preferences
      Name                                                  / Value
      browser.cache.disk.capacity                           / 358400
      browser.cache.disk.smart_size_cached_value            / 358400
      browser.cache.disk.smart_size.first_run               / false
      browser.cache.disk.smart_size.use_old_max             / false
      browser.places.smartBookmarksVersion                  / 4
      browser.startup.homepage_override.buildID             / 20121020030554
      browser.startup.homepage_override.mstone              / 19.0a1
      extensions.lastAppVersion                             / 19.0a1
      network.cookie.prefsMigrated                          / true
      places.history.expiration.transient_current_max_pages / 104326
      plugin.disable_full_page_plugin_for_types             / application/pdf
      privacy.sanitize.migrateFx3Prefs                      / true
Graphics
      Adapter Description / VMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 0x209)
      Device ID / Gallium 0.4 on llvmpipe (LLVM 0x209)
      Driver Version / 2.1 Mesa 8.0.4
      GPU Accelerated Windows / 0/5 Basic no information
      Vendor ID / VMware, Inc.
      WebGL Renderer / no information
      AzureCanvasBackend / cairo
      AzureContentBackend / none
      AzureFallbackCanvasBackend / none
JavaScript
      Incremental GC / true
Accessibility
      Activated / false
      Prevent Accessibility / 0
Library Versions
      NSPR / 4.9.3 Beta
      NSS / 3.14.0.1 Basic ECC
      NSSSMIME / 3.14.0.1 Basic ECC
      NSSSSL / 3.14.0.1 Basic ECC
      NSSUTIL / 3.14.0.1


OK - y'all should have enough to proceed, so I'm outta here...

Comment 10

[M ODonnell]

Oops... At the end of comment #8 I meant to say, "The feature in question continued to work in the other BROWSER WINDOWS", not "pages".

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to M ODonnell from comment #10)
> Oops... At the end of comment #8 I meant to say, "The feature in question
> continued to work in the other BROWSER WINDOWS", not "pages".

makes sense, looks like some variable tracking popup state is going out-of-sync

Comment 12

[Simona Badau, Desktop QA]

Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121113030658

I can also reproduce this issue on the latest Nightly on Ubuntu 12.04.

Steps to reproduce:
1. Launch Firefox 
2. I opened 3 new windows (Ctrl+N)
3. In the 4th Firefox window I opened 12 random web sites (I performed a Google search) and minimized it
4. In the 3th Firefox window I opened 10 random web sites and minimized it
5. In the 2nd Firefox window I opened 11 web sites and minimized it
6. In the first opened Firefox window I opened 11 sites and performed several downloads
7. In the first opened Firefox window -> click on the Downloads button (in the navigation toolbar)

Actual results:
The Downloads Panel refuses to open in the first opened window. On all the other windows the downloads panel opens just fine.

The problem is intermittent. I could reproduce the issue using the above steps to reproduce from the first time that i ever tried. 

After reloading the tabs on all the 4 Firefox windows and clicked the Downloads button - the issue reproduced again.

Comment 13

[Simona Badau, Desktop QA]

The issue is reproducible on all platforms and the way to reproduce it is to click really fast on the Downloads Indicator for a couple of times. 

The problem is still intermittent.

Steps to reproduce:
1. Launch Firefox
2. Click on the Downloads Indicator button a couple of times (sometimes it helps if there is a web site loading while clicking on the button) 

There is no need to open multiple windows or tabs as described in Comment 12.

Reproduced the issue on the latest Nightly on Windows 7, Ubuntu 12.04 and Mac OS X 10.8.

Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130131 Firefox/21.0
Build ID: 20130131031009

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

what's the ETA here?

Comment 16

[Caspy7]

I reproduced this in bug 839173 by beginning a download of a large file and then going to town clicking rapidly on the button.

Comment 17

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

there is no clear ETA nor steps to reproduce this, so removing from list of blockers considered there's less than one week to the merge.
Though, if we should ever figure out what's up, and the fix is easy, we can definitely consider asking for approval.

Comment 18

[Caspy7]

I can't speak to the ETA, but I described steps for reliably producing this in bug 839173.
1) Start a large download (for instance libreoffice http://www.libreoffice.org/download/ )
2) While downloading go to town clicking on the button as fast as possible.

I can do it every time. Within just a few seconds the button is non-functional.

Comment 19

[M ODonnell]

As a civilian I'm not sure what your release criteria are but I'll agree that this bug is probably not important enough to be a showstopper.  I'll note, though, that adding "intermittent" to the headline seems odd since the problem is fairly easy to reproduce...

Comment 21

[Caspy7]

Do we not, now, have the tools to see what is breaking when we reproduce this bug?