24170 - [Dogfood]Pref window empty after dismissed once

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P1)

Description

[Richard Zach]

On today's build Linux 2000.01.17.08, I get problems when I try to use the Pref
window a second time.

To reproduce:
1. Start Mozilla
2. Edit | Preferences
3. Click OK
4. Edit | Preferences

Actual result: Nothing happens, console outputs:

we don't handle eBorderStyle_close yet... please fix me
WEBSHELL+ = 4
nsXULKeyListenerImpl::Init()
nsXULKeyListenerImpl::Init()
WEBSHELL+ = 5

Expected result: Pref window comes up again

5. Edit | Preferences again

Actual result:  Pref window comesup, but the right side of the screen is empty,
for every selection.

Console output:

title string = [Preferences]
*** PREF_onpageload('pref-appearance');
*** user prefs
*** user prefs
*** user prefs
*** user prefs
*** prefindex = 2; prefvalue = 2
*** prefvalue = true
*** prefindex = 0; prefvalue = 2
*** prefvalue = false
*** prefindex = 1; prefvalue = 2
*** prefvalue = false
*** id & value: generalStartupBrowser : true
*** id & value: generalStartupMail : false
*** id & value: generalStartupEditor : false
*** id & value: generalStartupCalendar : false
*** id & value: browserChromeToolbarStyle2 : true
*** id & value: browserChromeToolbarStyle0 : false
*** id & value: browserChromeToolbarStyle1 : false
WEBSHELL- = 4
nsXULKeyListenerImpl::Init()
JavaScript Error: TypeError: window.arguments has no properties
URL: chrome://pref/content/pref.xul
LineNo: 53

nsXULKeyListenerImpl::Init()
WEBSHELL+ = 5

Expected result: Pref windows with content.

6. Select any of the preferences in the component pane on the left

Actual result: Nothing happens
Console outputs:

JavaScript Error: TypeError: window.handle has no properties

Expected result: Pref pane changes to preferences for selected component

Comment 1

[leger]

Putting on dogfood radar.

Comment 2

[sairuh (rarely reading bugmail)]

i don't know whether this is the same bug or not, but i actually got the right
panel to appear blank on the first try. (using today's 2000-011811 comm bits on
linux.) in fact, clicking OK to dismiss the menu doesn't even work --had to
click Cancel to do so...

console output:
WEBSHELL+ = 4
change lock icon to unlock - new document
nsXULKeyListenerImpl::Init()
nsXULKeyListenerImpl::Init()
WEBSHELL+ = 5
change lock icon to unlock - new document
title string = [Preferences]
! nsSecureBrowserUIImpl found: chrome://pref/content/pref.xul
change lock icon to unlock ?(chrome 0)
*** PREF_onpageload('pref-appearance');
*** user prefs
*** user prefs
*** user prefs
*** user prefs
*** prefindex = 2; prefvalue = 2
*** prefvalue = true
*** prefindex = 0; prefvalue = 2
*** prefvalue = false
*** prefindex = 1; prefvalue = 2
*** prefvalue = false
*** id & value: generalStartupBrowser : true
*** id & value: generalStartupMail : false
*** id & value: generalStartupEditor : false
*** id & value: generalStartupCalendar : false
*** id & value: browserChromeToolbarStyle2 : true
*** id & value: browserChromeToolbarStyle0 : false
*** id & value: browserChromeToolbarStyle1 : false
! nsSecureBrowserUIImpl found: chrome://pref/content/pref-appearance.xul
change lock icon to unlock ?(chrome 0)
*** going to save page data for tag: pref-appearance
*** newURL: chrome://messenger/content/pref-diskspace.xul
got a request
change lock icon to unlock - new document
! nsSecureBrowserUIImpl found: chrome://messenger/content/pref-diskspace.xul
change lock icon to unlock ?(chrome 0)
*** going to save page data for tag: pref-diskspace
JavaScript Error: TypeError: doc has no properties
URL: chrome://global/content/widgetStateManager.js
LineNo: 95

JavaScript Error: TypeError: doc has no properties
URL: chrome://global/content/widgetStateManager.js
LineNo: 95

JavaScript Error: TypeError: doc has no properties
URL: chrome://global/content/widgetStateManager.js
LineNo: 95

Comment 3

[matt]

ben,
you want to field this one.
Seems like it might have something to do with the widgetStateManager.js

Comment 4

[sairuh (rarely reading bugmail)]

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

Comment 5

[rickg]

Pref windows need to work for beta.

Comment 6

[don]

Hmmmm ... I think we need to fix this for M13 ...

Comment 7

[sairuh (rarely reading bugmail)]

just tried to repro this with today's linux comm bits (2000011909), but
couldn't. the Prefs dialog came up as expected; subsequent attempts still
allowed me to pick other categories (although the right panel takes a while to
load each time i change the category)...

additional note: not a prob on winNT (2000011909, comm).
[e-mail], do you still see this (with a more recent build)?

should this be marked wfm...?

Comment 8

[Richard Zach]

Checked, works on Linux 2000.01.19.08.  Marking WFM.

Comment 9

[Richard Zach]

...and verified.

Comment 10

[leger]

Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.