62787 - XML bindings fail to load when the profile manager dialog is up

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Simon Fraser [no longer active]]

XML bindings files are having their loads cancelled in Necko when the profile 
manager dialog is dismissed. Thus XBL bindings don't load, and the build goes to 
hell.

This seems worse when using files, not jars, in chrome, so it somewhat timing 
dependent.

Comment 1

[Simon Fraser [no longer active]]

This is a blocker for me: I need to use files in chrome.

Comment 2

[Simon Fraser [no longer active]]

Loads are being cancelled when the nsLoadGroup::Cancel() is called as we tear 
down the profile manager dialog. Hyatt thinks that the loads don't complete when 
the dialog is up because of some kind of modal dialog thing that stalls events.

Comment 3

[Brian 'netdragon' Bober]

What is your final error? Can you post the debug window results and your call
stack? I want to compare this to bug 62816
.

Comment 4

[Simon Fraser [no longer active]]

Yeah, it looks like the same bug.

Comment 5

[Peter Trudelle]

->moz0.8

Comment 6

[Fabian Guisset]

I am seeing the same thing. Additional informations :
-Started around 20 december.
How to reproduce it :
1)Get a fresh Mozilla zip build (I use win32)
2)Edit installed-chrome.txt to point to the un-jar'ed directories e.g. comm/
instead of comm.jar!
3)Save, start Mozilla
4)ProfileManager pops up, click "Start Mozilla".
5)Look at the console : Failed to load XBL bindings etc etc.
This only happens in the toolkit/ dir and classic/ and modern/ dirs. (haven't
tried blue/). Since it doesn't happen when using the jar archives, I suspect it
is a packaging issue.
Note : this prevents me from using the modern skin (if using the non-jar dirs),
but classic doesn't seem to affect anything.
Who should be CC'ed for packaging?
Using win32, so OS/PF to All/All

Comment 7

[David Hyatt]

Necko is giving me an error code for no apparent reason.  Nothing is wrong with 
the files.  This is Mac-only and only when building without JARs.

Reassigning to Necko component owner.

Comment 8

[Simon Fraser [no longer active]]

Huh? Isn't this the event processing bug that you (hyatt) and danm know about (at 
least to some degree)?

Comment 9

[chris hofmann]

sounds like no fix in hand,  affects only small set of
developers that aren't jaring stuff up...  

do the jars...
is that good enough work around for 0.8?

moving to m0.9 until some one screams

Comment 10

[Simon Fraser [no longer active]]

*scream*
For those skin developers who edit chrome all day, this bug is an absolute 
blocker. It also seems to be a serious and deep-rooted issue that needs shaking 
out now.

Comment 11

[neeti]

Simon,

What are the steps to reproduce this bug? Is it Mac only?

Neeti

Comment 12

[Simon Fraser [no longer active]]

Neeti: do a build with jars turned off. Make sure you have > 1 profile so that 
the profile manager dialog comes up. Run Mozilla. Note console warnings about XBL 
loading errors. Note that chrome loading fails.

Comment 13

[neeti]

I am not able to reproduce this with jars disabled on windows and linux. This is 
also working now on a Mac (simon's machine).

Marking WORKSFORME

Comment 14

[neeti]

--> worksforme

Comment 15

[Mike Pinkerton (not reading bugmail)]

i now see this every time i close the profile manager. with jars enabled.

Comment 16

[Mike Pinkerton (not reading bugmail)]

This is what I'm seeing now:

•••WARNING: XBL load did not complete until after document went away! Modal 
dialog bug?, file nsXBLService.cpp, line 343

Comment 17

[neeti]

This is the stack trace when nsLoadGroup::Cancel(..) is called.


nsLoadGroup::Cancel(nsLoadGroup * const 0x0146fea0, unsigned int 2152398850) 
line 213 
nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x0146eea0) line 277 + 31 bytes 
nsURILoader::Stop(nsURILoader * const 0x01455360, nsISupports * 0x0146eeb8) line 
853 + 23 bytes 
nsDocShell::Stop(nsDocShell * const 0x014607f0) line 1682 
nsDocShell::Destroy(nsDocShell * const 0x014607f4) line 1808 
nsWebShell::Destroy(nsWebShell * const 0x014607f4) line 1484 
nsXULWindow::Destroy(nsXULWindow * const 0x01463644) line 361 
nsWebShellWindow::Destroy(nsWebShellWindow * const 0x01463644) line 1734 + 9 
bytes 
nsChromeTreeOwner::Destroy(nsChromeTreeOwner * const 0x0146ed74) line 227 
GlobalWindowImpl::Close(GlobalWindowImpl * const 0x023eb424) line 2141 
nsAppShellService::Quit(nsAppShellService * const 0x00a12550) line 446 
XPTC_InvokeByIndex(nsISupports * 0x00a12550, unsigned int 6, unsigned int 0, 
nsXPTCVariant * 0x0012d3dc) line 139 
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x023ed8a0, 
nsXPCWrappedNative * 0x02d85e70, const
XPCNativeMemberDescriptor * 0x02d954c0, nsXPCWrappedNativeClass::CallMode 
CALL_METHOD, unsigned int 0, long
* 0x027b0234, long * 0x0012d5c4) line 934 + 42 bytes 
WrappedNative_CallMethod(JSContext * 0x023ed8a0, JSObject * 0x00e01b20, unsigned 
int 0, long * 0x027b0234, long *
0x0012d5c4) line 250 + 34 bytes 
js_Invoke(JSContext * 0x023ed8a0, unsigned int 0, unsigned int 0) line 813 + 23 
bytes 
js_Interpret(JSContext * 0x023ed8a0, long * 0x0012e344) line 2706 + 15 bytes 
js_Invoke(JSContext * 0x023ed8a0, unsigned int 1, unsigned int 2) line 830 + 13 
bytes 
js_InternalInvoke(JSContext * 0x023ed8a0, JSObject * 0x00e553f0, long 41762328, 
unsigned int 0, unsigned int 1, long *
0x0012e4dc, long * 0x0012e46c) line 902 + 20 bytes 
JS_CallFunctionValue(JSContext * 0x023ed8a0, JSObject * 0x00e553f0, long 
41762328, unsigned int 1, long * 0x0012e4dc,
long * 0x0012e46c) line 3334 + 31 bytes 
nsJSContext::CallEventHandler(nsJSContext * const 0x023ed590, void * 0x00e553f0, 
void * 0x027d3e18, unsigned int 1,
void * 0x0012e4dc, int * 0x0012e4d8, int 0) line 940 + 33 bytes 
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02d80f44) line 154 + 64 bytes 
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02b6f220, 
nsIDOMEvent * 0x02d80f44,
nsIDOMEventTarget * 0x02b690d8, unsigned int 8, unsigned int 7) line 1035 + 19 
bytes 
nsEventListenerManager::HandleEvent(nsIPresContext * 0x023e8c00, nsEvent * 
0x0012ef00, nsIDOMEvent * * 0x0012edc4,
nsIDOMEventTarget * 0x02b690d8, unsigned int 7, nsEventStatus * 0x0012ef48) line 
1955 + 39 bytes 
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02b690d0, nsIPresContext * 
0x023e8c00, nsEvent *
0x0012ef00, nsIDOMEvent * * 0x0012edc4, unsigned int 1, nsEventStatus * 
0x0012ef48) line 3675 
PresShell::HandleDOMEventWithTarget(PresShell * const 0x02458510, nsIContent * 
0x02b690d0, nsEvent * 0x0012ef00,
nsEventStatus * 0x0012ef48) line 5545 + 39 bytes 
nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x023e8c00, nsGUIEvent * 
0x0012f0fc) line 181 
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x00e6b1a8, 
nsIPresContext * 0x023e8c00, nsGUIEvent *
0x0012f0fc, nsEventStatus * 0x0012f3f0) line 128 
PresShell::HandleEventInternal(nsEvent * 0x0012f0fc, nsIView * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f3f0) line
5513 + 41 bytes 
PresShell::HandleEventWithTarget(PresShell * const 0x02458510, nsEvent * 
0x0012f0fc, nsIFrame * 0x00e6b1a8, nsIContent
* 0x02b690d0, unsigned int 1, nsEventStatus * 0x0012f3f0) line 5471 + 22 bytes 
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x02b980c0, nsIPresContext *
0x023e8c00, nsMouseEvent * 0x0012f4fc, nsEventStatus * 0x0012f3f0) line 2340 + 
61 bytes 
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x02b980c8, 
nsIPresContext * 0x023e8c00, nsEvent *
0x0012f4fc, nsIFrame * 0x00e6b1a8, nsEventStatus * 0x0012f3f0, nsIView * 
0x024231a0) line 1439 + 28 bytes 
PresShell::HandleEventInternal(nsEvent * 0x0012f4fc, nsIView * 0x024231a0, 
unsigned int 1, nsEventStatus * 0x0012f3f0) line
5518 + 43 bytes 
PresShell::HandleEvent(PresShell * const 0x02458514, nsIView * 0x024231a0, 
nsGUIEvent * 0x0012f4fc, nsEventStatus *
0x0012f3f0, int 1, int & 1) line 5425 + 25 bytes 
nsView::HandleEvent(nsView * const 0x024231a0, nsGUIEvent * 0x0012f4fc, unsigned 
int 28, nsEventStatus * 0x0012f3f0,
int 1, int & 1) line 377 
nsViewManager::DispatchEvent(nsViewManager * const 0x02423680, nsGUIEvent * 
0x0012f4fc, nsEventStatus *
0x0012f3f0) line 2055 
HandleEvent(nsGUIEvent * 0x0012f4fc) line 68 
nsWindow::DispatchEvent(nsWindow * const 0x02424ee4, nsGUIEvent * 0x0012f4fc, 
nsEventStatus &
nsEventStatus_eIgnore) line 704 + 10 bytes 
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f4fc) line 725 
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4028 + 
21 bytes 
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4273 
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 16384310, long * 
0x0012f8cc) line 3009 + 24 bytes 
nsWindow::WindowProc(HWND__ * 0x00250e82, unsigned int 514, unsigned int 0, long 
16384310) line 959 + 27 bytes 
USER32! 77e7124c() 

Comment 18

[Gagan]

david (dprice): can you verify with doug/neeti that the loadgroup is being set
properly and that we are cleaning up correctly as the dialog box goes away? 

And is this a correct understanding that it's only an assertion?

Comment 19

[Gagan]

->dprice

Comment 20

[Simon Fraser [no longer active]]

This bug is back with a vengence today, and blocking me from running debug 
builds. We HAVE to nail this one.

Comment 21

[Simon Fraser [no longer active]]

Attachment: Results of a NSPR_LOG_MODULES=LoadGroup:5,nsFileTransport:5,nsRequestObserverProxy:5,nsStreamListenerProxy:5

Comment 22

[sairuh (rarely reading bugmail)]

i saw this occur using 2001.05.10.08-moz on linux, right after i had used
2001.05.08.0x comm bits.

got the dialog: Error creating browser instance

console output:
Failed to load XBL document
jar:resource:///chrome/toolkit.jar!/content/global/xulBindings.xml
JavaScript error: 
chrome://navigator/content/navigator.js line 366: window.XULBrowserWindow has no
propertie
s

unfortunately, tried repeating it, but it doesn't seem to lend itself to
consistent reproducibility. :(

Comment 23

[Simon Fraser [no longer active]]

Here's something weird: remove requests are using platform-style paths:

0[d91af6c]: LOADGROUP [dae2fa8]: Removing request dd3b734 
Development:Trees:Editor tree:editor 
src:mozilla:dist:viewer_debug:chrome:classic:skin:classic:global:button-def-
active-right-btm.gif status 0 (count=-1).
0[d91af6c]: LOADGROUP [dae2fa8]: Unable to remove request dd3b734. Not in group!

and hence all failing on mac!

Comment 24

[Simon Fraser [no longer active]]

Hrmm, ignore that last comment. Requests are identified by address, not name 
(though it still seems like a bug that nsIRequest::GetName sometimes returns a 
platform file path, and sometimes resturns a URL; the calls returning a native 
file path are those that propagate down to nsFileTransport).

Comment 25

[Simon Fraser [no longer active]]

Attachment: Stack for the xulbindings.xml load that subsequently gets cancelled

Comment 26

[Simon Fraser [no longer active]]

So here's what was happening. At some point, Conrad hooked up profile observer 
stuff that caused nsChromeRegistry::RefreshSkins to be called synchronously. This 
means that on pressing the OK button on the profile picker, we'd call 
RefreshSkins, which would blow away the chrome and image caches, and refesh all 
existing windows *including the profile picker window which was still up*. This 
caused a reload of xulBindings.xml which would promptly get cancelled when the 
profile manager dialog was closed. It would be a crapshoot as to whether it would 
finish loading (amongst all the other css/image reloading) before the window 
closed.

The fix is to have nsChromeRegistry::LoadProfileDataSource() just flush the 
chrome caches, and not try to refresh all of the open windows.

Comment 27

[Simon Fraser [no longer active]]

Attachment: Patch, sr=hyatt

Comment 28

[Simon Fraser [no longer active]]

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

Comment 29

[Simon Fraser [no longer active]]

Fixed.

Comment 30

[sairuh (rarely reading bugmail)]

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