Closed Bug 305288 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: XPConnect, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta4

People

(Reporter: plutot, Assigned: bzbarsky)

References

Details

(Keywords: regression, smoketest, verified1.8)

Attachments

(1 file)

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
Confirmed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050819 Firefox/1.0+ ID:2005081920
Status: UNCONFIRMED → NEW
Ever confirmed: true
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]
*** Bug 305307 has been marked as a duplicate of this bug. ***
Maybe the Hardware/OS fields of this bug should be set to All? (because 305307
is a duplicate of this bug)
OS: Windows XP → All
Hardware: PC → All
Severity: major → blocker
Flags: blocking1.8b4?
Summary: Blank options dialog when browser.preferences.animateFadeIn is set to True. → Blank options dialog on OS X (i.e. browser.preferences.animateFadeIn is set to True).
Target Milestone: --- → Firefox1.5
doesn't happen on 2005-08-18-06.
Keywords: regression
Summary: Blank options dialog on OS X (i.e. browser.preferences.animateFadeIn is set to True). → Blank options dialog when browser.preferences.animateFadeIn is true (default on Mac)
Flags: blocking1.8b4? → blocking1.8b4+
Blocks: 305403
*** Bug 305509 has been marked as a duplicate of this bug. ***
Keywords: smoketest
Josh - you were the last one to touch the fade in/out stuff it appears. Any
thoughts?
(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. 
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.
Blocks: 303981
*** Bug 305403 has been marked as a duplicate of this bug. ***
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.
No longer blocks: 305403
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
Blocks: 305426
Assignee: nobody → dbradley
Component: Preferences → XPConnect
Product: Firefox → Core
QA Contact: preferences → pschwartau
Target Milestone: Firefox1.5 → ---
Version: unspecified → Trunk
Assignee: dbradley → bzbarsky
Status: NEW → ASSIGNED
Attachment #193525 - Flags: superreview?(jst)
Attachment #193525 - Flags: review?(jst)
Priority: -- → P1
Summary: Blank options dialog when browser.preferences.animateFadeIn is true (default on Mac) → [FIX]Blank options dialog when browser.preferences.animateFadeIn is true (default on Mac)
Target Milestone: --- → mozilla1.8beta4
I suspect Boris's fix will also address Bug #305421
Blocks: 305421
Blocks: 305622
Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

r+sr=jst
Attachment #193525 - Flags: superreview?(jst)
Attachment #193525 - Flags: superreview+
Attachment #193525 - Flags: review?(jst)
Attachment #193525 - Flags: review+
Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

We need this on branch...
Attachment #193525 - Flags: approval1.8b4?
Comment on attachment 193525 [details] [diff] [review]
Make the equality op actually happen for timers

indeed we do.
Attachment #193525 - Flags: approval1.8b4? → approval1.8b4+
Fixed, trunk and branch
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
*** Bug 302160 has been marked as a duplicate of this bug. ***
Blocks: splitwindows
Verified on Mac Deer Park build 2005-08-24-05-mozilla1.8
Status: RESOLVED → VERIFIED
No longer blocks: 305622
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!
Keywords: fixed1.8verified1.8
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.
I've also tried to switch the settings of the browser.prefereces.animateFadeIn setting. This makes no difference.
(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.
You need to log in before you can comment on or make changes to this bug.