Schedule native event callback from a timer

NEW
Unassigned

Status

()

11 years ago
5 years ago

People

(Reporter: mats, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Follow-up from bug 389931.

There's a small risk that we never schedule the callback event that
a nested native event loop needs to start processing XPCOM events.

It can be fixed by setting up a timer before the call to
ProcessNextNativeEvent() and then Cancel it afterwards
(we can re-use the same timer object).

My first thought was to add it in DoProcessNextNativeEvent():
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp&rev=1.8&root=/cvsroot&mark=133#116
but since this is a private method that is only called from 
OnProcessNextEvent() we could wrap a series of calls there instead
(for efficiency).
(Reporter)

Comment 1

11 years ago
Also, if we introduce this timer, maybe we can remove the scheduling
of callback events from OnDispatchedEvent() and depend on the timer to
do it instead...  posting these events and then processing them in the
XPCOM state with a return in NativeEventCallback() seems like a waste
of time.  This part is slightly riskier though since the callback event
in itself has the side effect of unblocking a native loop that blocked
waiting for an event.  I think it should work, but the cocoa widget
code calls NativeEventCallback() from state eEventLoopNone so we need
to look into that first.
(Reporter)

Updated

11 years ago
Blocks: 389931
Instead of stopping and starting the timer, we could keep it running with a fixed period (say 100ms) as long as there are XPCOM events queued. That might be more efficient.

Maybe we should not even fix this for FF3 final. It's a very edge case and there are perf risks.
(Reporter)

Updated

5 years ago
Assignee: matspal → nobody
You need to log in before you can comment on or make changes to this bug.