Closed
Bug 397439
Opened 17 years ago
Closed 17 years ago
Hang when Venkman brings itself to the front
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta1
People
(Reporter: philor, Assigned: smichaud)
Details
(Keywords: hang, regression)
Attachments
(1 file, 1 obsolete file)
8.26 KB,
patch
|
mark
:
review+
roc
:
superreview+
roc
:
approval1.9+
|
Details | Diff | Splinter Review |
I don't have an exact date, since I don't build often enough, but my 2007-09-17-22 build still worked, and 2007-09-20-22 didn't, a range which makes me strongly suspect bug 395397. STR: 1. Build with --enable-extensions=default,venkman and run your build 2. Tools - Javascript Debugger, do anything that will bring it to the front (Debug - uncheck Exclude Browser Files, Debug - Throw Trigger - Stop for Exceptions will make following any link bring it up) 3. Trigger it to raise itself, and it and the browser will both be hung Nothing browser-specific, the same thing happens triggering a breakpoint in Thunderbird, and Mac-specific, Linux still works fine.
Assignee | ||
Comment 1•17 years ago
|
||
I can reproduce a strange sort of hang in the 2007-09-20-01-trunk SeaMonkey nightly, but not in the 2007-09-19-01-trunk SeaMonkey nightly. Command+t from the main browser window was all I needed to do to cause a JavaScript error :-) I'm currently compiling two Minefield builds (with the Venkman extension) -- one whose source is dated just before my appshell patch (bug 395397) was landed, and one whose source is dated just afterwards (so that the only difference between the two builds is the presence or absence of my appshell patch). The main thread isn't completely blocked -- you can still move browser windows around (including the Venkman window). But none of the menus work, and neither does the rest of the browser UI.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•17 years ago
|
||
OK, this bug is definitely the fault of my new appshell patch. The hang is in [NSRunLoop acceptInputForMode:beforeDate:] (in nsAppShell::ProcessNextNativeEvent()), and at a higher level in jsdService::EnterNestedEventLoop() (in js/jsd/jsd_xpc.cpp), where it calls NS_ProcessNextEvent() in tight loop. I've already made provisions to special-case modal event loops in nsAppShell::ProcessNextNativeEvent() (without this special-casing you get the same kind of hang). Now is appears that I will need to use the same kind of special-casing for all nested Gecko event loops. It's not obvious how I'll be able to do this ... but I have some ideas.
Assignee | ||
Updated•17 years ago
|
Assignee: joshmoz → smichaud
Assignee | ||
Comment 3•17 years ago
|
||
Here's a fix. I did need to add special-casing for "all nested Gecko event loops" ... but I also needed to define "nested" in a rather complicated way. I'm now using [NSApp nextEventMatchingMask:...] and [NSApp sendEvent:] a bit more often than previously. But I tested to make sure that doing so doesn't re-introduce the problems that caused me to avoid using them for all native events.
Attachment #282342 -
Flags: review?(joshmoz)
Attachment #282342 -
Flags: review?(joshmoz) → review?(mark)
Assignee | ||
Comment 4•17 years ago
|
||
This patch is against the most recent code, but is otherwise unchanged. Inadvertently the previous one was made against slightly outdated copies of nsAppShell.mm and nsAppShell.h.
Attachment #282342 -
Attachment is obsolete: true
Attachment #282412 -
Flags: review?(mark)
Attachment #282342 -
Flags: review?(mark)
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9 M9
Updated•17 years ago
|
Attachment #282412 -
Flags: review?(mark) → review+
Attachment #282412 -
Flags: superreview?(roc)
Comment on attachment 282412 [details] [diff] [review] Fix rev1 (update for current builds) so I was kinda right about the nested event loops, eh?
Attachment #282412 -
Flags: superreview?(roc)
Attachment #282412 -
Flags: superreview+
Attachment #282412 -
Flags: approval1.9+
Assignee | ||
Comment 6•17 years ago
|
||
Only kinda right :-) There's nothing simple or straightforward about OS X or Gecko event processing :-(
Assignee | ||
Comment 7•17 years ago
|
||
Landed on trunk.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•