773267 - The Downloads Panel flickers at the top left of the screen before anchoring to the button

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect)

Description

[:Paolo Amadini]

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.

Comment 1

[:Paolo Amadini]

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.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

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

Starting investigation...

Comment 3

[Girish Sharma [:Optimizer]]

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

Comment 4

[Mike Conley (:mconley) (:⚙️)]

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...

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v1

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 6

[:Paolo Amadini]

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.

Comment 7

[:Paolo Amadini]

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.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v2

Excellent - thanks for the feedback, Paolo.

Comment 9

[Marco Bonardo [:mak]]

Comment on attachment 668159 [details] [diff] [review]
Patch v2

Review of attachment 668159 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

Comment 10

[Mike Conley (:mconley) (:⚙️)]

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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/48c1645f720f

Comment 12

[Girish Sharma [:Optimizer]]

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 ?

Comment 13

[Mike Conley (:mconley) (:⚙️)]

(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?

Comment 14

[Marco Bonardo [:mak]]

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.

Comment 15

[Girish Sharma [:Optimizer]]

Here is a screencast showing the same.

http://youtu.be/0oDc4A4ARnU

Comment 16

[Mike Conley (:mconley) (:⚙️)]

(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?

Comment 17

[Girish Sharma [:Optimizer]]

Oh, okay : filed bug 800424

Comment 18

[Simona Badau, Desktop QA]

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.