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.

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)

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.

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.

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

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?

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?

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.

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.