plutot Reporter
	Description • 19 years ago

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

	Aaron Slunt
	Comment 1 • 19 years ago

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

	Unknown W. Brackets
	Comment 2 • 19 years ago

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]

	Kees Grinwis
	Comment 3 • 19 years ago

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

	Kees Grinwis
	Comment 4 • 19 years ago

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

	Dave Townsend [:mossop]
	Comment 5 • 19 years ago

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

	Asaf Romano (gone)
	Comment 6 • 19 years ago

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

	Dave Townsend [:mossop]
	Comment 7 • 19 years ago

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

	Peter van der Woude [:Peter6]
	Comment 8 • 19 years ago

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

	Peter van der Woude [:Peter6]
	Comment 9 • 19 years ago

suspect bug 304871

	Dave Townsend [:mossop]
	Comment 10 • 19 years ago

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

	Zach Lipton [:zach]
	Comment 11 • 19 years ago

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

	Scott MacGregor
	Comment 12 • 19 years ago

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

	Scott MacGregor
	Comment 13 • 19 years ago

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.

	Scott MacGregor
	Comment 14 • 19 years ago

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

	Scott MacGregor
	Comment 15 • 19 years ago

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.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 16 • 19 years ago

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

	Scott MacGregor
	Comment 18 • 19 years ago

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

	Johnny Stenback (:jst)
	Comment 19 • 19 years ago

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

r+sr=jst

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 20 • 19 years ago

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

We need this on branch...

	Scott MacGregor
	Comment 21 • 19 years ago

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

indeed we do.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 22 • 19 years ago

Fixed, trunk and branch

	shutdown
	Comment 23 • 19 years ago

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

	Tracy Walker [:tracy]
	Comment 24 • 19 years ago

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

	David Fedoruk
	Comment 25 • 19 years ago

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!

	Pieter Woltjer
	Comment 26 • 19 years ago

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.

	Pieter Woltjer
	Comment 27 • 19 years ago

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

	Dave Townsend [:mossop]
	Comment 28 • 19 years ago

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