121057 - Prefs panel "Advanced|Scripts & Windows" can only be visited once per session

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Brian Teague]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120
BuildID:    2002012009

The first time I visit the "Advanced|Scripts and Windows" pref panel, everything
works fine.  Subsequent visits result in a download dialog, trying to get
chrome://communicator/content/pref/pref-scripts.xul.  Only restarting Mozilla
allows access to that pref panel again, but only once, and the problem repeats.

Reproducible: Always
Steps to Reproduce:
1.  Open Preferences.  Choose Advanced|Scripts & Windows.
2.  Choose another pref panel.
3.  Try to go back to Scripts & Windows.

Actual Results:  A download dialog appeared.

Expected Results:  Display the pref panel!

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Ummm..  yes.  that's odd.

Confirming this on linux 2002011921 also.  Doron?

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Okay this was caused by the checkin to fix bug 116306.  Backing that out fixes this.

->hyatt and nominating for 0.9.8.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Note: the scripts/windows panel is the only one with this problem.  I can click
twice thru every other pane just fine.

Comment 4

[R.K.Aa.]

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

Comment 5

[Luke Koleszar]

OS -> All

Also seeing this on WinME 2002012103

Comment 6

[John Morrison]

Ok, this fails in CSSLoaderImpl::LoadAgentSheet called from
nsXULDocument::AddPrototypeSheets like the stack below. It fails since it is
trying to load an non-existent stylesheet 'dialogOverlay.css' that is declared
in pref-scripts.xul, the xul for that pref panel.

http://lxr.mozilla.org/seamonkey/search?string=dialogoverlay.css

So, that failure propagates back up the stack and the cached XUL document is
not opened (note: the role of the XUL cache is the reason that this works the
first time and fails the second).  The app then decides to download the url
since it couldn't get a viewer (somewhere further up the stack).


nsXULDocument::AddPrototypeSheets(nsXULDocument * const 0x03477538) line 6445
nsXULDocument::StartDocumentLoad(nsXULDocument * const 0x03477538, const char * 
0x018d45b4 `string', nsIChannel * 0x0354eeb0, nsILoadGroup * 0x00000001, 
nsISupports * 0x032ed65c, nsIStreamListener * * 0x0012fd18, int 0x00000001, 
nsIContentSink * 0x00000000) line 780
nsContentDLF::CreateRDFDocument(nsContentDLF * const 0x03477538, const char * 
0x018d45b4 `string', nsIChannel * 0x00000000, nsILoadGroup * 0x02657e80, const 
char * 0x0012fc88, nsISupports * 0x032ed65c, nsISupports * 0x034e8718, 
nsIStreamListener * * 0x0012fd18, nsIContentViewer * * 0x0012fc00) line 527 + 
26 bytes
nsContentDLF::CreateInstance(nsContentDLF * const 0x034e3768, const char * 
0x018d45b4 `string', nsIChannel * 0x034e1798, nsILoadGroup * 0x02657e80, const 
char * 0x0012fc88, nsISupports * 0x032ed65c, nsISupports * 0x00000000, 
nsIStreamListener * * 0x0012fd18, nsIContentViewer * * 0x0012fc00) line 276 + 
30 bytes
nsDocShell::NewContentViewerObj(nsDocShell * const 0x032ed638, const char * 
0x0012fc88, nsIRequest * 0x034e1798, nsILoadGroup * 0x02657e80, 
nsIStreamListener * * 0x0012fd18, nsIContentViewer * * 0x0012fc00) line 3664 + 
39 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x032ed638, const char * 
0x0012fc88, nsIRequest * 0x034e1798, nsIStreamListener * * 0x0012fd18) line 
3550
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x034e1798, 
const char * 0x0012fc88, int 0x00000000, nsIRequest * 0x034e1798, 
nsIStreamListener * * 0x0012fd18, int * 0x00010000) line 108
nsDocumentOpenInfo::DispatchContent(nsDocumentOpenInfo * const 0x03477538, 
nsIRequest * 0x034e1798, nsISupports * 0x00000000) line 362
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x03472088, 
nsIRequest * 0x00000000, nsISupports * 0x00000000) line 226 + 14 bytes
nsCachedChromeChannel::HandleStartLoadEvent(PLEvent * 0x033499a0) line 433
PL_HandleEvent(PLEvent * 0x033499a0) line 591
PL_ProcessPendingEvents(PLEventQueue * 0x100340d8) line 520 + 6 bytes
_md_EventReceiverProc(HWND__ * 0x00000001, unsigned int 0x00401fc2, unsigned 
int 0x01086f80, long 0x00000000) line 1071 + 10 bytes
nsAppShellService::Run(nsAppShellService * const 0x01086f80) line 303
main1(int 0x00000001, char * * 0x00323c30, nsISupports * 0x00322c30) line 1285 
+ 9 bytes
main(int 0x00000001, char * * 0x00323c30) line 1625 + 26 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x0013348c, 
HINSTANCE__ * 0x00400000) line 1643 + 21 bytes
MOZILLA! WinMainCRTStartup + 308 bytes
KERNEL32! 77e87903()


The first-level 'fix' for this is to remove the bogo xml-stylesheet PI from 
pref-scripts.xul. This fixes the problem with viewing that particular panel
twice. I'll attach a patch.

The (open) question of whether the AddPrototypeSheets should be more tolerant
of the failure in LoadAgentSheet is left to hyatt. (I expect that the answer 
is no, but maybe it should assert or warn).

Comment 7

[John Morrison]

Attachment: patch; remove xml-stylesheet from file pref-scripts.xul for non-existent dialogOverlay.css

Comment 8

[John Morrison]

This'll do the job for 0.9.8, and the second part may be no action required. 
Can I get r=/sr=/a= and someone to check this in.

Comment 9

[Blake Ross]

Comment on attachment 65961 [details] [diff] [review]
patch; remove xml-stylesheet from file pref-scripts.xul for non-existent dialogOverlay.css

sr=blake

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 65961 [details] [diff] [review]
patch; remove xml-stylesheet from file pref-scripts.xul for non-existent dialogOverlay.css

r=[e-mail]

Thanks jrgm!  Tested and works.

Comment 11

[Brendan Eich [:brendan]]

a=[e-mail] for 0.9.8 checkin -- thanks jrgm!

/be

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

jrgm, I flagged timeless down to check this in for you.
a=sherriff (alecf) via IRC as a mac build is red.

Thanks again for fixing this jrgm.  Good detective work :)

marking fixed.

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.01.24.0x comm bits on linux rh7.2, mac 10.1.2 and win2k.