On Linux, I've sometimes observed that the Downloads Panel appears briefly at the top left of the screen before going to its final position, anchored to the Downloads indicator.

This happens often, though not all the times, the first time the panel is displayed in a window where it was never shown before. It does not seem to flicker again after the first time. We load the panel element on demand using an overlay: http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/downloads.js#86 An them we show it asynchronously some time after populating it: http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/downloads.js#297 The version I'm trying out contains the patches in bug 760607, bug 748381, bug 747903, and bug 748160, though I suspect the issue is visible also in current nightly builds.

I'm able to reproduce this pretty reliably on Ubuntu. Starting investigation...

For me, it flickers even after the first time Windows 7 Aero HWA on

At least for the case I'm seeing on Ubuntu, I think this is caused by two calls to _openPopupIfDataReady in rapid succession when initializing the panel. My initial solution is to add a new state, "kStateAlmostShown" to the list of panel states for when we've lined up the call to open the popup, but we're waiting for something (in this case, we're waiting to ensure that the anchor overlay is loaded and that we have a handle on the anchor). This seems to fix the issue for me on Ubuntu - but it's quite possible, since I'm new to this part of the codebase, that there's a case or condition that I'm not accounting for. Let me know! Patch forthcoming...

Paolo: I know you're a bit swamped with other stuff right now, but am I on the right track here? Alternatively, let me know if there's someone else I should be directing my f/r requests to. Thanks! -Mike

Comment on attachment 667488 [details] [diff] [review] Patch v1 Review of attachment 667488 [details] [diff] [review]: ----------------------------------------------------------------- Looks good! I reviewed the state flow and wrote a couple of notes below. I think you can ask Marco for the final review on the next iteration. ::: browser/components/downloads/content/downloads.js @@ +68,5 @@ > /** The panel will be shown as soon as possible. */ > get kStateShowing() 2, > + /** The panel is almost shown - we're just waiting to get a handle on the > + anchor */ > + get kStateAlmostShown() 3, nit: I think we could rename kStateShowing to kStateWaitingData and call the new state kStateWaitingAnchor, or something similar (kStateShowWaitData, ...), now that we have more states. nit: Full stop at end of comment (the final reviewer would ask, I might as well point it out now :-)) @@ +326,5 @@ > "after_end", 0, 0, false, null); > } > }.bind(this)); > + > + this._state = this.kStateAlmostShown; The getAnchor function may or may not invoke the callback synchronously, so the state should updated before the call. It's also possible (though extremely rare) that a panel hiding request is received before the overlay is loaded and the callback invoked, so at the beginning of the callback we should check that the state is still the expected one.

Not related to this bug at all, but while you're working on panel issues, I'd like to point out the test in bug 780837 comment 8 where something weird is happening with panel styling (observed on Linux Mint, didn't test on other platforms). Maybe this could provide some clue (or some confusion :-)) for cases like bug 797547.

Excellent - thanks for the feedback, Paolo.

Comment on attachment 668159 [details] [diff] [review] Patch v2 Review of attachment 668159 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!

Landed on mozilla-inbound as https://hg.mozilla.org/integration/mozilla-inbound/rev/48c1645f720f

I can still see the flickering in 11th Oct Nightly. Windows 7 HWA on Should I reopen this after someone's confirmation that they can also see th flickering ?

(In reply to Girish Sharma [:Optimizer] from comment #12) > I can still see the flickering in 11th Oct Nightly. > Windows 7 HWA on > Should I reopen this after someone's confirmation that they can also see th > flickering ? Hrm. Very strange. I can't reproduce this. Can anyone else?

This clearly fixed a bug as reported by many, if there are more causes giving similar symptoms I'd suggest filing a new separate report than reopening this. It may happen in different conditions.

Here is a screencast showing the same. http://youtu.be/0oDc4A4ARnU

(In reply to Girish Sharma [:Optimizer] from comment #15) > Here is a screencast showing the same. > > http://youtu.be/0oDc4A4ARnU Thanks Girish - that cleared things up. I think what we're seeing here is a separate issue. This bug dealt with the panel spawning to the far left of the window before snapping to the anchor position. Would you mind filing a separate bug with that screencast?

Oh, okay : filed bug 800424

Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121113030658 Verified on the latest Nightly that the the Downloads Panel doesn't flicker at the top left of the screen the first time the panel is displayed in a window where it was never shown before.