365018 - Drop down menus flicker in preference panel when switching from one panel to another

Status: RESOLVED WORKSFORME

(Firefox :: Settings UI, defect)

Description

[Voon Siong Wong]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20061223 Firefox/2.0.0.2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20061223 Firefox/2.0.0.2pre

Drop down menus (where exist) in the preference panel flickers for a split second when switching from one panel to another. Examples would be the "Default font" menu under "Content", and "Accept cookies from ..." under "Privacy".

Reproducible: Always

Steps to Reproduce:
1. Open Preference Panel
2. Switch between panels with drop down menus, such as "main", "content", "privacy", etc.
3.

Actual Results:  
Drop down menus flickers once when panel first appears

Expected Results:  
No flicker at all.

I've narrowed it down using official nightlies to 2006-11-12-06-mozilla1.8 working ok, but 2006-11-13-03-mozilla1.8 flickers. Regression likely introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=348304 checked in that period.

This also means that the official Firefox 2.0.0.0 does *NOT* exhibit this behavior, but 2.0.0.1 does.

Further, Thunderbird 2.0b1 also exhibits this problem.

Comment 1

[Voon Siong Wong]

Ok. Confirming that backing out the aforementioned bug (348304) allows the preference panel to work as expected. (I tested with home-made builds)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Smaug, any idea what's up here?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

I think because of some async stuff bug 348304 added, the size
of the dropdown menu is updated after a panel is first time "loaded",
and that causes some flickering.

I don't have a mac, and haven't seen the problem on Windows or Linux.
Actually I tested one mac too, and couldn't see any problems there...

Comment 4

[Boris Zbarsky [:bzbarsky]]

So what's flickering?  The actual dropdown, or the place where it drops down from?

Also, did you test trunk or branch builds?  I wouldn't be all that surprised if there is no problem on trunk...

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #4)
> Also, did you test trunk or branch builds?  I wouldn't be all that surprised if
> there is no problem on trunk...
> 

It was a 2.0.0.1 running on a mac.
And I've tested 2.0.0.1 and trunk on Linux and Windows and
haven't seen any problems.
So to me it is not quite clear what the problem actually is, 
but hopefully someone who can reproduce the bug can comment...

Comment 6

[Voon Siong Wong]

Boris, Smaug, thanks for looking into this. I downloaded the latest nightlies for both branch and trunk (2007-02-04-07-mozilla1.8 and 2007-02-04-04-trunk respectively) and still find the problem on the *branch*. Tested both with new profiles each.

With the *branch* builds, it's only the dropdown menus - the first thing you see before you click on anything. I don't know if you call that "actual dropdown" or "place where it drops down from". But you don't have to click on the dropdown to see it. Just switch to a preference panel that has a dropdown menu and it will flicker for a second.

With the *trunk* builds, the entire preference panel flickers when switching from one panel to the next. I believe that is a known issue with the move to thebes (I think), but I don't use the trunk much, so I can't really comment on that.

Once again, if I backed out bug 348304 and built my own, then the flicker is gone. I see this behaviour on a G4 and a G5, don't have any other machines to test with.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So what does the flicker look like?  Does it look like the dropdown actually drops down for a sec and then disappears?  Or does it look like the combobox width or height is wrong for a sec and then corrects itself?

Comment 8

[Voon Siong Wong]

I'll just copy/paste/edit your description - "It look like the combobox *width* is wrong for a sec and then corrects itself."

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm....  smaug, when do we trigger menu generation?  Is it something that has to happen after frame construction, basically?

Would it be possible/safe for presshell to flush out the generation before processing reflow commands?

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Menu generation is triggered during reflow, and before 348304, it was 
really done during reflow by setting an attribute :(

Comment 11

[Boris Zbarsky [:bzbarsky]]

Could we use a reflow callback instead of a completely asynchronous event?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Reflow callbacks are handled in DidDoReflow, and generating menus 
(== modifying DOM by setting attributes) there would be pretty unsafe :(

Comment 13

[Jay Patel [:jay]]

Nominating for the next round.  Let's try to get a handle on this for 1.8.1.3/1.8.0.12.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Well... 

5947 void
5948 PresShell::DidDoReflow()
5949 {
5950   HandlePostedAttributeChanges();
5951   HandlePostedReflowCallbacks();

So it better be sorta safe -- we already do attribute changes there. ;)

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Fortunately PostedAttributeChanges are used only for 
nsGfxScrollFrameInner::SetScrollbarEnabled, which is called
for native anonymous content so mutation events don't propagate...
Have to file a bug to remove HandlePostedReflowChanges.

Comment 16

[Tracy Walker [:tracy]]

I am seeing this on trunk build from 20070205 on Mac.  I do NOT see it on 2.0.0.1.
The category menu isn't really flickering, it's more like jumping up and down.  On Mac, the bottom of the Prefs dialog window slides up and down to adjust to the various category sizes.  When it incrementally does that, the dialog window title bar flickers (disappears and reappears).  I response, the Category menu bar rapidly jumps up(no title bar present) to fill the missing title bar space and then back down (title bar present) until the dialog finishes resizing.

Comment 17

[Boris Zbarsky [:bzbarsky]]

So perhaps we should post the async instantiate event from frame construction, not reflow?  And process them in the presshell before entering reflow?  That is, replace an event with just an annotation in the presshell?

Comment 18

[Daniel Veditz [:dveditz]]

Not going to block the branches for a minor cosmetic problem with no owner. If you get a trunk fix that's branch-safe you can ask for approval on the patch.

Comment 19

[Voon Siong Wong]

Still broken in 2.0.0.3, but the latest 2.0.0.4pre builds don't appear to have this problem anymore. It looks like either bug 375196 and/or bug 336744 resolved the issue. I can't view either bug, as they are security bugs, but at least it appears to be working properly now.

Thanks for looking. Closing bug as WFM.

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

If this is fixed it was probably bug 368501.