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).
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.
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.
You need to log in before you can comment on or make changes to this bug.