305288 - [FIX]Blank options dialog when browser.preferences.animateFadeIn is true (default on Mac)

Status: VERIFIED FIXED

(Core :: XPConnect, defect, P1)

Description

[plutot]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819 Firefox/1.0+

If browser.preferences.animateFadeIn is set to True via about:config, the
options window goes blank. Returns to normal when it is set to false.

Reproducible: Always

Steps to Reproduce:
1. Set browser.preferences.animateFadeIn is set to True via about:config
2. Navigate to Tools--->Options

Actual Results:  
The options window appeared but it was blank (except the OK/Cancel buttons and
the tabs up top)

Expected Results:  
The options window should have appeared with the relevant text.

No problems with the official 20050819 build. 
Build ID with timestamp:
-------------------------
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819
Firefox/1.0+ ID:2005081920

Comment 1

[Aaron Slunt]

Confirmed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050819 Firefox/1.0+ ID:2005081920

Comment 2

[Unknown W. Brackets]

Well, the reason it's not fading in is simple - the timer in
widgets/preferences.xml is used for fading in and animating, and checks:

aTimer == this._animateTimer
aTimer == this._fadeTimer

For some reason (since 2005-08-10 when I'm certain it worked) these checks are
now always false.  Unfortunately, this is where we go deeper than I currently
understand Mozilla's codebase.

An easy kludge was to replace the checks above with a "this._timerPhase"
variable (0, 1, then 2 meaning none, animating, and fading respectively.)  This
fixes that, and lets me see that bug #283697 is no longer a problem for me too.

It's probably something simple, though.  Both aTimer and this._animateTimer are
nsITimers, and since other places in Mozilla also compare such timers... well,
it's probably somewhere else.

I hope this helps someone fix the bug, though.

Thanks,
-[Unknown]

Comment 3

[Kees Grinwis]

*** Bug 305307 has been marked as a duplicate of this bug. ***

Comment 4

[Kees Grinwis]

Maybe the Hardware/OS fields of this bug should be set to All? (because 305307
is a duplicate of this bug)

Comment 5

[Dave Townsend [:mossop]]

Tracked the regression window on this on trunk builds to between the 2005081907
and 2005081915 builds. Following checkins were in that time:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-19+06%3A50&maxdate=2005-08-19+14%3A27&cvsroot=%2Fcvsroot

Comment 6

[Asaf Romano (gone)]

doesn't happen on 2005-08-18-06.

Comment 7

[Dave Townsend [:mossop]]

Regression on branch occured at a similar time, between 2005081906 and 2005081914

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-19+06%3A00&maxdate=2005-08-19+13%3A27&cvsroot=%2Fcvsroot

Comment 8

[Peter van der Woude [:Peter6]]

correct regression window:

works in 20050819_1220pdt build
fails in 20050819_1422pdt build

http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-19+11%3A43%3A00&maxdate=2005-08-19+13%3A26%3A00&cvsroot=%2Fcvsroot

Comment 9

[Peter van der Woude [:Peter6]]

suspect bug 304871

Comment 10

[Dave Townsend [:mossop]]

*** Bug 305509 has been marked as a duplicate of this bug. ***

Comment 11

[Zach Lipton [:zach]]

Josh - you were the last one to touch the fade in/out stuff it appears. Any
thoughts?

Comment 12

[Scott MacGregor]

(In reply to comment #9)
> suspect bug 304871

I backed out the changes for Bug #304871 and the bug is still present so that
isn't the culprit. 

Comment 13

[Scott MacGregor]

This regression was caused by Bug 303981

Backing out the global window changes for that patch made the options dialog
start working again. I haven't started to look at why that is yet though.

Comment 14

[Scott MacGregor]

*** Bug 305403 has been marked as a duplicate of this bug. ***

Comment 15

[Scott MacGregor]

Not that it means much, but the specific part of Bug 303981 that causes this to
break is the call to:

    // InitClassesWithNewWrappedGlobal() for the new inner window sets
    // the global object in cx to be the new wrapped global. We don't
    // want that, but re-initializing the outer window will fix that
    // for us. This has to happen unconditionally since we clear the
    // outer window's scope unconditionally.
    scx->InitContext(this);


Skipping the call to InitContext makes the timers fire properly for fading in
the preferences window. I'm not suggesting that's the fix.

Comment 16

[Boris Zbarsky [:bzbarsky]]

So the reason for the problem described in comment 2 is that the objects being
compared are XPCWrappedNatives for the same nsITimer but wrapped in different
scopes.  More precisely, the two scopes are two different inner windows for the
same outer window:

(gdb) p (class nsGlobalChromeWindow*)$id1
$19 = (nsGlobalChromeWindow *) 0x89fec00
(gdb) p ((class nsGlobalChromeWindow*)$id2)
$20 = (nsGlobalChromeWindow *) 0x8a124e0
(gdb) p ((class nsGlobalChromeWindow*)$id2)->mInnerWindow
$21 = (nsPIDOMWindow *) 0x0
(gdb) p ((class nsGlobalChromeWindow*)$id2)->mOuterWindow
$22 = (nsPIDOMWindow *) 0xb5bbe6e4
(gdb) p ((class nsGlobalChromeWindow*)$id1)->mInnerWindow
$23 = (nsPIDOMWindow *) 0x0
(gdb) p ((class nsGlobalChromeWindow*)$id1)->mOuterWindow
$24 = (nsPIDOMWindow *) 0xb5bbe6e4

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Make the equality op actually happen for timers

Comment 18

[Scott MacGregor]

I suspect Boris's fix will also address Bug #305421

Comment 19

[Johnny Stenback (:jst)]

Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

r+sr=jst

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

We need this on branch...

Comment 21

[Scott MacGregor]

Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

indeed we do.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Fixed, trunk and branch

Comment 23

[shutdown]

*** Bug 302160 has been marked as a duplicate of this bug. ***

Comment 24

[Tracy Walker [:tracy]]

Verified on Mac Deer Park build 2005-08-24-05-mozilla1.8

Comment 25

[David Fedoruk]

What ever happened between 20050816 Firefox/1.0+ (August 16) and 20050824
Firefox/1.6a1 cured the problem in DeerPark at least. I no longer see it..
thoguh I can still duplicate it in the older version. Things were still the same
in teh nightly from the 19th so this change happened somewhere between the 19th
and today's build.... I'm checking this as i'm writing this entry...

Something has changed. Now the Camino build from 2005082308 (v0.9a2+) works..
NOT the build from the 19th which is still on the Camino website at the latest
nightly (Cut and paste from the download page:
Build: Aug 19, 2005
Mirror: mirror1.mirrors.tds.net (216.165.129.134))I got this newer build
directly from the mozilla ftp site in /pub/mozilla.org/camino/nightly/latest. 

So problem solved!

Comment 26

[Pieter Woltjer]

I've installed firefox 1.5 on my Windows XP machine yesterday (the official release). Installation done under administrator account. Everything seems to go well, but the other user-account on my pc has exactly the problem as described in this bug: the options dialag is blank except for the oke/cancel/apply buttons.

The Administrator account does not have this problem. I've tried the following: -De-install completely
-Change the limited user account to an account with full permissions
-Install again under the limited user account
Same problem occurs: administrator account has the normal options dialog, limited account (which now has admin rights) has the blank options dialog.

Comment 27

[Pieter Woltjer]

I've also tried to switch the settings of the browser.prefereces.animateFadeIn setting. This makes no difference.

Comment 28

[Dave Townsend [:mossop]]

(In reply to comment #26)
> I've installed firefox 1.5 on my Windows XP machine yesterday (the official
> release). Installation done under administrator account. Everything seems to go
> well, but the other user-account on my pc has exactly the problem as described
> in this bug: the options dialag is blank except for the oke/cancel/apply
> buttons.
> 

That is not the problem described in this bug. This bug is fixed. The problem you are having is that you are using a theme that is not compatible with Firefox 1.5. Switch to the default theme and it will work.