Closed
Bug 301791
Opened 19 years ago
Closed 3 years ago
Fix plevent handling with nested event loops on Mac
Categories
(Core :: XPCOM, defect, P5)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: sfraser_bugs, Unassigned)
References
()
Details
(Whiteboard: qa-not-actionable)
Currently, Mac does no filtering of plevents when modal event loops are being used. This means that plevents can fire in the wrong context, leading to problems liek those in bug 300057. It looks like we need to use something akin to PL_GetEventQueueSelectFD() to get at the CFRunLoopSourceRef, and use that to ensure that only the CFRunLoopSourceRef for the current event queue is registered with the runloop at any one time. I might have to touch plevent.h to fix this.
Reporter | ||
Updated•19 years ago
|
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: -- → P1
Reporter | ||
Updated•19 years ago
|
Reporter | ||
Comment 1•19 years ago
|
||
It sucks that code in widget/mumble/appshell has to reach over into xpcom/threads/plevent.c and dick with stuff. This also makes it hard for us, because we're going to have to somehow get at the CFRunLoopSourceRef for the old event queue and disable it, then enable the new one.
Reporter | ||
Comment 2•19 years ago
|
||
Currently the Mac plevent code doesn't support making an event queue for a thread that isn't the current thread. Do we ever do that? I think what I'm going to do here is to move the CFRunLoopAddSource() over to nsAppShell::ListenToEventQueue(), so I'll add a void* accessor in plevent.h to get at "platform data" or something. PL_GetEventQueueSelectFD() won't cut it on a 64-bit machine.
Reporter | ||
Comment 3•19 years ago
|
||
The patch in bug 300057 contains the fix for this.
Reporter | ||
Updated•19 years ago
|
Assignee: sfraser_bugs → dougt
Status: ASSIGNED → NEW
Comment 4•18 years ago
|
||
Is this still an issue once bug 326273 is fixed?
Updated•18 years ago
|
Depends on: nsIThreadManager
Comment 5•18 years ago
|
||
I don't think my patch for bug 326273 will solve this bug. Events will still be just as unfiltered as before. We're going to need to figure out how to deal with this issue for all platforms once my patch for bug 326273 lands.
Comment 7•6 years ago
|
||
Decreasing the priority as no update for the last 2 years on this bug. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage about the priority meaning.
Priority: P1 → P5
Comment 8•3 years ago
|
||
Hi Simon, does this issue still occur with our latest builds? or can we close this issue with WFM ? seems like a pretty old issue.
Flags: needinfo?(sfraser_bugs)
Whiteboard: qa-not-actionable
Reporter | ||
Updated•3 years ago
|
Flags: needinfo?(sfraser_bugs)
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•