Closed Bug 301791 Opened 16 years ago Closed 3 months ago

Fix plevent handling with nested event loops on Mac

Categories

(Core :: XPCOM, defect, P5)

PowerPC
macOS
defect

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.
Severity: normal → critical
Status: NEW → ASSIGNED
Priority: -- → P1
Blocks: 300057
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.
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.
The patch in bug 300057 contains the fix for this.
Assignee: sfraser_bugs → dougt
Status: ASSIGNED → NEW
Blocks: 314072
Blocks: cocoa
Is this still an issue once bug 326273 is fixed?
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.
No longer blocks: cocoa
mass reassigning to nobody.
Assignee: dougt → nobody
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

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
Flags: needinfo?(sfraser_bugs)
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.