Closed Bug 816986 Opened 7 years ago Closed 7 years ago

Downloads sometimes don't appear in the downloads panel

Categories

(Firefox :: Downloads Panel, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mconley, Assigned: mconley)

References

Details

Attachments

(1 file)

dolske has been experiencing this one, and I'm having no luck reproducing it, but I'm storing my notes here:

STR:

1) Start a download
2) Open the panel

What happens?

Download is not listed there, even though we see progress in the button.

What's expected?

The download should be available when we open the panel.

Interesting side-note - if he opens up new Firefox windows, the download exists in those windows' panels.
if the download happened really early in the browser session, could be a race condition in the lazy init code.
(In reply to Marco Bonardo [:mak] from comment #1)
> if the download happened really early in the browser session, could be a
> race condition in the lazy init code.

Yep, that's my suspicion too. I'm putting together a logging patch in bug 816254 that I'm going to get dolske to try.
Assignee: nobody → mconley
Hey Simona - does this problem sound at all familiar to you?
Here's dolske's logging output:

    Starting a download...
     
    Downloads DownloadsCommon.jsm: Creating a new DownloadsDataItem with downloadId = 1
    Downloads downloads.js: A new download data item was added - aNewest =  true
    Downloads downloads.js: Adding a new DownloadsViewItem to the downloads list.  aNewest =  true
    Downloads downloads.js: The downloads item count has changed - we are tracking 1 downloads in total.
    Downloads downloads.js: Setting the panel's hasdownloads attribute to true.
    Downloads downloads.js: A new download data item was added - aNewest =  true
    Downloads downloads.js: Adding a new DownloadsViewItem to the downloads list.  aNewest =  true
    Downloads downloads.js: The downloads item count has changed - we are tracking 1 downloads in total.
    Downloads downloads.js: Setting the panel's hasdownloads attribute to true.
    Downloads DownloadsCommon.jsm: A download changed its state to:  -1
    Downloads DownloadsCommon.jsm: Attempting to notify that a new download has started.
    Downloads DownloadsCommon.jsm: Showing new download notification.
    WARNING: NS_ENSURE_TRUE(![bitmapRep isPlanar] && (unsigned int)[bitmapRep bytesPerPlane] == desiredImageSize * desiredImageSize * 4 && [bitmapRep bitsPerPixel] == 32 && [bitmapRep samplesPerPixel] == 4 && [bitmapRep hasAlpha] == YES) failed: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 261
    WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 184
    WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2957
    WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
    WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2957
    WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
    WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2957
    WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
    WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2957
    WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
    WARNING: NS_ENSURE_TRUE(![bitmapRep isPlanar] && (unsigned int)[bitmapRep bytesPerPlane] == desiredImageSize * desiredImageSize * 4 && [bitmapRep bitsPerPixel] == 32 && [bitmapRep samplesPerPixel] == 4 && [bitmapRep hasAlpha] == YES) failed: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 261
    WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 184
    Downloads DownloadsCommon.jsm: A download changed its state to:  5
    WARNING: blocked access to response header: file /Users/dolske/build/mozilla-central/content/base/src/nsXMLHttpRequest.cpp, line 4028
    WARNING: Unable to report memory for Worker (122b11000)! It is either using ctypes or is in the process of being destroyed: file /Users/dolske/build/mozilla-central/dom/workers/WorkerPrivate.cpp, line 1562
    WARNING: Unable to report memory for Worker (122b11000)! It is either using ctypes or is in the process of being destroyed: file /Users/dolske/build/mozilla-central/dom/workers/WorkerPrivate.cpp, line 1562
    Downloads DownloadsCommon.jsm: A download changed its state to:  0
    WARNING: NS_ENSURE_TRUE(![bitmapRep isPlanar] && (unsigned int)[bitmapRep bytesPerPlane] == desiredImageSize * desiredImageSize * 4 && [bitmapRep bitsPerPixel] == 32 && [bitmapRep samplesPerPixel] == 4 && [bitmapRep hasAlpha] == YES) failed: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 261
    WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 184
    WARNING: NS_ENSURE_TRUE(![bitmapRep isPlanar] && (unsigned int)[bitmapRep bytesPerPlane] == desiredImageSize * desiredImageSize * 4 && [bitmapRep bitsPerPixel] == 32 && [bitmapRep samplesPerPixel] == 4 && [bitmapRep hasAlpha] == YES) failed: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 261
    WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/image/decoders/icon/mac/nsIconChannelCocoa.mm, line 184
     
     
     
    dl done
     
     
    WARNING: blocked access to response header: file /Users/dolske/build/mozilla-central/content/base/src/nsXMLHttpRequest.cpp, line 4028
    WARNING: WriteDataCacheBlocks() failed.: file /Users/dolske/build/mozilla-central/netwerk/cache/nsDiskCacheStreams.cpp, line 545
    Downloads downloads.js: Opening the downloads panel.
    Downloads downloads.js: Attempting to initialize DownloadsPanel for a window.
    Downloads downloads.js: DownloadsPanel is already initialized.
    Downloads downloads.js: Waiting for the downloads panel to appear.
    Downloads downloads.js: Opening downloads panel popup.
    Downloads downloads.js: Downloads panel has shown.
    Downloads downloads.js: Downloads panel has hidden.
     
     
    ^ opened panel, empty for this window
     
     
    WARNING: blocked access to response header: file /Users/dolske/build/mozilla-central/content/base/src/nsXMLHttpRequest.cpp, line 4028
    Downloads downloads.js: Opening the downloads panel.
    Downloads downloads.js: Attempting to initialize DownloadsPanel for a window.
    Downloads downloads.js: DownloadsPanel is already initialized.
    Downloads downloads.js: Waiting for the downloads panel to appear.
    Downloads downloads.js: Opening downloads panel popup.
    Downloads downloads.js: Downloads panel has shown.
    Downloads downloads.js: Downloads panel has hidden.
     
     
    ^ opened panel, filled for 2nd window
Here's the version with a bit less noise, I forgot to update my tree with the fix for the mox-icon failure (bug 815512):

Starting download....

Downloads DownloadsCommon.jsm: Creating a new DownloadsDataItem with downloadId = 1
Downloads downloads.js: A new download data item was added - aNewest =  true
Downloads downloads.js: Adding a new DownloadsViewItem to the downloads list.  aNewest =  true
Downloads downloads.js: The downloads item count has changed - we are tracking 1 downloads in total.
Downloads downloads.js: Setting the panel's hasdownloads attribute to true.
Downloads downloads.js: A new download data item was added - aNewest =  true
Downloads downloads.js: Adding a new DownloadsViewItem to the downloads list.  aNewest =  true
Downloads downloads.js: The downloads item count has changed - we are tracking 1 downloads in total.
Downloads downloads.js: Setting the panel's hasdownloads attribute to true.
Downloads DownloadsCommon.jsm: A download changed its state to:  -1
Downloads DownloadsCommon.jsm: Attempting to notify that a new download has started.
Downloads DownloadsCommon.jsm: Showing new download notification.
MOZ_EVENT_TRACE sample 1354316204626 55
WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2956
WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2956
WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2956
WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x8000FFFF: file /Users/dolske/build/mozilla-central/content/base/src/nsContentUtils.cpp, line 2956
WARNING: NS_ENSURE_TRUE(pusher.Push(aBoundElement)) failed: file /Users/dolske/build/mozilla-central/content/xbl/src/nsXBLProtoImplMethod.cpp, line 321
Downloads DownloadsCommon.jsm: A download changed its state to:  5


Open panel....


Downloads downloads.js: Opening the downloads panel.
Downloads downloads.js: Attempting to initialize DownloadsPanel for a window.
Downloads downloads.js: DownloadsPanel is already initialized.
Downloads downloads.js: Waiting for the downloads panel to appear.
Downloads downloads.js: Opening downloads panel popup.
Downloads downloads.js: Downloads panel has shown.

(empty panel)
Attached image There you are!
Mike asked me to take a look at the panel during a download, to see if the richlistbox (id="downloadsListBox") actually had something in it or not...

DOMi indeed shows it's filled, and I see the "X of Y MB" attributes ticking away. So the item is _there_, it's just not showing. Thought it might be some weird invalidation bug, but I can change the "Show all downloads" label and it updates in the panel.

On a whim I tried deleting the entire panel footer from the DOM... Ah-ha! The download item shows up, but is... shrunken. The footer was actually overlapping it. So seems like something isn't being sized correctly for some reason...
Here's the screenshot that dolske sent me of what this looks like:

http://cl.ly/image/0D2L2j1s0b0Q

I haven't been able to reproduce this at all, and I got sancus to try reproducing it on his Retina Macbook, but still no luck.
Ok, I think we're narrowing in. When sancus switched to his discrete GPU, he was able to reproduce. Here was his about:support Graphics section when that happened:

Graphics
 
        Device ID
        0x fd5
 
        GPU Accelerated Windows
        1/1 OpenGL
 
        Vendor ID
        0x10de
 
        WebGL Renderer
        NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine
 
        AzureCanvasBackend
        quartz
 
        AzureContentBackend
        none
 
        AzureFallbackCanvasBackend
        none

However, this works fine with the integrated GPU.
Cc'ing Steven Michaud, who was basically 100% awesome the last time we had a graphics issue with Retina on Thunderbird.

Steven - any idea what might be going wrong here?
> Steven - any idea what might be going wrong here?

No idea at all.  And I'm afraid it'll be a while before I can get to this.

But I have the same hardware as sancus (a "Mid 2012" Retina MBP).  And I did notice something strange (which may or may not be relevant):

The "WebGL Renderer" in about:support is always "NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine" (the "discrete" graphics hardware), whether or not "automatic graphics switching" is checked in the Energy Saver pref panel.

The "Device ID" and "Vendor ID" change as expected.

I tested on OS X 10.7.5 in a recent mozilla-central nightly.
Cool - Cc'ing Jonathan Kew as well, in case he has any ideas.
(In reply to Steven Michaud from comment #10)
> The "WebGL Renderer" in about:support is always "NVIDIA Corporation --
> NVIDIA GeForce GT 650M OpenGL Engine" (the "discrete" graphics hardware),
> whether or not "automatic graphics switching" is checked in the Energy Saver
> pref panel.
> 
> The "Device ID" and "Vendor ID" change as expected.

To the best of my knowledge, "automatic graphics switching" unchecked means that you will always use the discrete card, and checked means it will switch to the IGPU when no application is forcing use of the discrete card.

For me, when the discrete card is off, my WebGL Renderer is "Intel Inc. -- Intel HD Graphics 4000 OpenGL Engine", as expected. The best way to confirm which GPU is enabled is to use the third party app gfxcardstatus @ http://gfx.io/ - you can even use it to force the IGPU on at all times.

Note that I'm on Mountain Lion 10.8.2, not 10.7.5.
What I'm concerned about is that FF may (somehow) sometimes be using the "wrong" driver for the current video hardware.  But I'm not entirely sure what the "WebGL Renderer" setting means in about:support.
Interestingly, I don't see what I reported in comment #10 if gfxCardStatus is running and is set to either "Integrated only" or "Discrete only".

(And yes, I restart FF between tests.)

Benoit, do you have any idea what could be going on here?  Either this bug itself, or the oddness I report in comment #10?
sancus, please try turning off "Use hardware acceleration if available" (in FF's Preferences : Advanced : General), to see if this makes any difference.
(Following up comment #15)

And check to see whether gfxCardStatus makes any difference -- whether or not its running, and (if its running) testing its different settings.

I don't expect it to (at least on OS X 10.8.2).  But this is a very strange bug, and you never know.
Flags: needinfo?(bgirard)
My Gfx info from about:support:

  Graphics

        Device ID
        0x 166

        GPU Accelerated Windows
        2/2 OpenGL

        Vendor ID
        0x8086

        WebGL Renderer
        NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine

        AzureCanvasBackend
        quartz

        AzureContentBackend
        none

        AzureFallbackCanvasBackend
        none
(In reply to Steven Michaud from comment #10)
> The "WebGL Renderer" in about:support is always "NVIDIA Corporation --
> NVIDIA GeForce GT 650M OpenGL Engine" (the "discrete" graphics hardware),
> whether or not "automatic graphics switching" is checked in the Energy Saver
> pref panel.
> 

This is expected. We actively disallow WebGL from running using the integrated GPU. To run on the integrated GPU an app must support dynamic switching which web content does not guarantee. Until GPU switching is exposed to web content this will remain the case. We currently have no such plans. This means hitting WebGL on any tab will switch your entire system to your discrete GPU.

While gfxCardStatus can overwrite this behavior this is not supported so I wouldn't read into the behavior we get in this configuration. I do however recommend using gfxCardStatus to list which applications are requesting the discrete GPU. As long as the're a single request then the whole system will be running with the discrete GPU.
Flags: needinfo?(bgirard)
If we're seeing GFX corruption we should file that as a separate bug. In this case it's best o run with an accelerated window with gfxCardStatus in 'd' and 'i' but without using the force. Close any program listed by gfxCardStatus to test with 'i', then plug an external monitor to force 'd'. Then test once more with 'layers.acceleration.disabled:true'. This should narrow down whether it's a drive bug with a renderer or a gecko corruption.
(In reply to Mike Conley (:mconley) from comment #3)
> Hey Simona - does this problem sound at all familiar to you?

I haven't seen this until now. I'll try to reproduce it and post back.
I haven't been able to reproduce this on my mini Mac 10.7.5 (with or without HWA) with NVIDIA GeForce 9400 OpenGL Engine. Unfortunately I don't have a MacBook Pro to test this.
I suspect this is an issue that only (potentially) occurs on hi-dpi displays. Just a guess at this point, but it feels like the sort of thing that might happen if the panel size gets "locked" by the addition of width/height attributes to one of the XUL elements. I wonder if this might happen in nsXULPopupManager::PopupResized as a result of a spurious size "mismatch" due to conversion back and forth between device and display pixels.
dolske:

I think we might need you to do a little bit of debugging if you have a moment.

Would you mind setting a breakpoint at nsXULPopupManager::PopupResized, reproducing the bug, and then showing us the values of the following:

aSize.width
aSize.height
(after line 370)
currentSize.width
currentSize.height
currCSS.width
currCSS.height
newCSS.width
newCSS.height

Thanks,

-Mike
Flags: needinfo?(dolske)
Well, this is annoying. I can't reproduce the bug in my own builds (debug or not, opt or not), but I can with the current official Nightly. (All running against the same profile.)

Wonder what the odds are that something else fixed this in the last 24 hours?

FWIW, the printf logging I added (to take gdb out of the mix) sometimes seems to have a really big number for one of the sizes when opening the panel:

---- nsXULPopupManager::PopupResized ----
aSize:    870 x 280
currSize: 26090 x 8370
currCSS:  435 x 140
newCSS:   435 x 140

Is that expected?
Flags: needinfo?(dolske)
Yes - currSize is in appUnits, at 60 appUnits per CSS pixel (or 30 per device pixel).
(In reply to Justin Dolske [:Dolske] from comment #24)
> Well, this is annoying. I can't reproduce the bug in my own builds (debug or
> not, opt or not), but I can with the current official Nightly. (All running
> against the same profile.)
> 
> Wonder what the odds are that something else fixed this in the last 24 hours?
> 

Hm. How about last night's Nightly? Did we just catch a lucky break?
Flags: needinfo?(dolske)
Indeed, I can no longer reproduce this with Nightly. O_o

Seems like whatever the cause was, it likely only affected some subset of users using Retina displays, so probably not worth bisecting. I'll just keep an eye out for it happening again.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dolske)
Resolution: --- → WORKSFORME
Spooky bug is spooky.

\o/?
Given that we don't really know what caused this, or what "fixed" it, I'm concerned that the underlying issue may still be lurking somewhere.

Bug 814434 comment 11, 13, and 20 seem to describe an issue that might be a manifestation of the same problem. Please be on the lookout for any recurrence, and file a new bug with clear STR if we can find any.
You need to log in before you can comment on or make changes to this bug.