Closed Bug 62787 Opened 24 years ago Closed 23 years ago

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

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: sfraser_bugs, Assigned: sfraser_bugs)

References

Details

Attachments

(3 files)

Results of a NSPR_LOG_MODULES=LoadGroup:5,nsFileTransport:5,nsRequestObserverProxy:5,nsStreamListenerProxy:5
690.22 KB, text/plain
Details
Stack for the xulbindings.xml load that subsequently gets cancelled
8.90 KB, text/plain
Details
Patch, sr=hyatt
1.81 KB, patch
Details | Diff | Splinter Review 
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.
This is a blocker for me: I need to use files in chrome.
Severity: normal → blocker
Priority: P3 → P2
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.

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

->moz0.8
Target Milestone: --- → mozilla0.8
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
OS: Mac System 8.5 → All
Hardware: Macintosh → All
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.
Assignee: hyatt → neeti
Component: XP Toolkit/Widgets → Networking
QA Contact: jrgm → tever
Huh? Isn't this the event processing bug that you (hyatt) and danm know about (at 
least to some degree)?

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
Target Milestone: mozilla0.8 → mozilla0.9
*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.

Simon,

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

Neeti


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.

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
--> worksforme
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
i now see this every time i close the profile manager. with jars enabled.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: mozilla0.9 → mozilla0.9.1
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

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() 
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?
->dprice
Assignee: neeti → dprice
Status: REOPENED → NEW
This bug is back with a vengence today, and blocking me from running debug 
builds. We HAVE to nail this one.

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

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

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.
Assignee: dprice → sfraser
*** Bug 78110 has been marked as a duplicate of this bug. ***
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 76365 has been marked as a duplicate of this bug. ***
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: