Closed
Bug 337481
Opened 18 years ago
Closed 18 years ago
startup problems after nsIThreadManager landing [@ nsNodeInfo::GetNamespaceURI]
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jaas, Assigned: mark)
References
Details
Attachments
(2 files)
Clean build of Cocoa Firefox on Mac OS X 10.4 (gcc4) after Darin's nsIThreadManager landing... 1. Delete profile (start fresh) 2. Launch Firefox First of all, I can't click on any of the options in the import data window. After dismissing the window the browser just hangs with no windows and no menu bar. After quitting and relaunching the browser crashes on start.
Updated•18 years ago
|
Attachment #221614 -
Attachment is patch: false
Comment 2•18 years ago
|
||
I crash pretty much the same way with a regular Tinderbox build (atlantia) (fetched 20060511, 11::20am Japan Standard time) - time stamp on server was 10-May-2006 21:29.
I get some feedback in the console about not being able to get the hidden window from the appshell. Did Darin's thread manager stuff change the timing of hidden window creation?
Assignee | ||
Comment 5•18 years ago
|
||
My [broken?] appshell, I'll take. See 337550.
Assignee: joshmoz → mark
Comment 6•18 years ago
|
||
Yesterday's (2006-05-11) and today's Firefox nightlies don't start up for me at all. I do get an icon on the dock, but when I click on it all I see is a default Application menu. No windows open, and the only way out is force quit. Restarting gives the same behavior again. I don't crash, though.
Assignee | ||
Comment 7•18 years ago
|
||
Occurs with Carbon too, then. Here's what I wrote on irc on the subject: it may actually be a cross-plat issue but we're more susceptible to it on the mac because i have us running the native loop in a system routine the other platforms retrieve and dispatch a single system event only once and then return so if there's a case where something's not calling us away from the system loop, we'd get stuck because we go back to blocking waiting for a new system event after processing a system event until called away from the loop, where other platforms would be blocked by waiting for an event, and as soon as you moved the mouse or whatever, they'd process the system event and then return and let gecko events fire
Assignee | ||
Comment 8•18 years ago
|
||
nsBaseAppShell: if (mProcessingNextNativeEvent) used to be if (mRunWasCalled) appears related
Assignee | ||
Comment 9•18 years ago
|
||
More notes in bug 337550 comment 17.
Updated•18 years ago
|
Severity: major → blocker
Comment 10•18 years ago
|
||
FWIW, the SeaMonkey 2006-05-13-01 build from <http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/bm-xserve01-trunk/seamonkey-1.5a.en-US.mac.dmg> did work for me without any problems under OS X 10.4.6/PPC.
Comment 11•18 years ago
|
||
(In reply to comment #10) > FWIW, the SeaMonkey 2006-05-13-01 build from > <http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/bm-xserve01-trunk/seamonkey-1.5a.en-US.mac.dmg> > did work for me without any problems under OS X 10.4.6/PPC. > But it doesn't work on 10.3.9...
Comment 12•18 years ago
|
||
So the stack trace in comment 1 indicates that we're messing with the DOM after the layout module has shut down. I believe Benjamin has a proposed patch to fix issues like that in bug 331117.
Depends on: 331117
Assignee | ||
Comment 13•18 years ago
|
||
That's right. This bug should really be about the stack traces in comment 1 and comment 3, and doesn't appear to be strictly related to the new threads manager or appshells at this point. The other things I was talking about in this bug more properly belong in bug 337550.
Assignee | ||
Updated•18 years ago
|
Summary: startup problems after nsIThreadManager landing → startup problems after nsIThreadManager landing [@ nsNodeInfo::GetNamespaceURI]
I crash with the same stack with a pretty standard (opt-with-symbols, no cocoa options) Firefox trunk build on 10.4.6 on x86, as of about 10 hours ago. It is cramping my style something fierce, I must say.
Comment 15•18 years ago
|
||
see also bug 337481 which is for the non-cocoa widgets version of this crash.
Comment 16•18 years ago
|
||
*** Bug 338329 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 17•18 years ago
|
||
Not cocoa-specific. I'm putting this into layout because that's where the crash is.
No longer blocks: cocoa
Component: Widget: Cocoa → Layout
Assignee | ||
Comment 18•18 years ago
|
||
Fixed by checkin of bug 331117.
Assignee | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•