338225 - Deal with nested native event loops spawned from native events

Status: RESOLVED FIXED

(Core :: Widget, defect, P1)

Description

[Darin Fisher]

Deal with nested native event loops spawned from native events

Currently, when this happens, we do not process any gecko events.  That seems problematic.  Prior to threadmanager, we didn't have this bug.  We should find a way to make nsBaseAppShell::NativeEventCallback determine that it needs to process some gecko events.  See bug 337824 for details on my previous failed attempt at fixing this issue.

Comment 1

[Darin Fisher]

To be more precise, this problem only occurs when nsIThread::ProcessNextEvent is called.  Then, it may happen that a native event is processed, which results in a modal native event loop being run (e.g., a modal file selection dialog).

Comment 2

[Mark Mentovai]

*** Bug 346108 has been marked as a duplicate of this bug. ***

Comment 3

[Håkan Waara]

I think this is a problem in Camino too, when we do native mouse tracking (for custom buttons like bookmarks on the toolbar).

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Bug 356720 is no longer a dup of this bug.  Instead I've made bug
356720 depend on this one.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

As best I can tell, this bug (like bug bug 356720) has been fixed on
the Mac (in Cocoa Widgets) by my patch for bug 395397.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

What's left to do here then?  I see 1.9+ was requested, is that still valid?

Comment 10

[Martijn Wargers (dead)]

See bug 337761, this hasn't been fixed on windows yet.

Comment 11

[Recall]

Martijn, it is the other way round you need to get this fixed first according to Robert O'Callahan. This will then allow other bugs such as https://bugzilla.mozilla.org/show_bug.cgi?id=405198 to start making progress.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

A number of bugs are claimed to depend on this one, all having to do
with dragging items within or into the Places Organizer (Bookmarks :
Show All Bookmarks or Bookmarks : Organize Bookmarks), including the
following (not a full list):

bug 337761
bug 405198
bug 405625

This may be true on Windows and Linux, but it isn't true on OS X (more
on this in my next comment).

All of these problems still exist on OS X.  This tells me that
additional factors are involved.  And while fixing this bug may be
necessary to fix the bugs listed above (and their friends) on Windows
and Linux, it probably won't be sufficient.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #12)

The Flash plugin is a plain-vanilla NPAPI plugin that receives all of
its events from the browser, and even performs timer-driven activity
on idle or null events sent by the browser.  So if you stop the
processing of Gecko events, the Flash plugin will stop processing
periodic events.

1) Run Minefield and open a page that contains lots of noisy Flash
   objects (ones that update their displays on a timer,
   http://www.vg.no/ should do).

2) Open the Places Organizer (Bookmarks : Show All Bookmarks in recent
   nightlies), and arrange the two windows so that neither obscures
   the other.

3) Start dragging some object (a bookmark or a folder) within the
   Places Organizer.  On Windows you'll observe that, for as long as
   the drag operation continues, the Flash objects will stop updating
   their displays.  But on OS X you'll observe the opposite -- the
   Flash objects keep updating their displays, even while the dragging
   continues.  (I haven't tested on Linux, but I assume you'll get the
   same results there as on Windows.)

Comment 14

[Jim Mathies [:jimm]]

Flash on windows throws around a lot of custom windowing events, which are piped around as nsIRunnable events to prevent cpu spikes -

http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp#165

http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp#330

Using drag and drop as an example (bug 337761) dragging something would freeze up processing of these events which I'm guessing is the reason for the difference.

Comment 15

[Jim Mathies [:jimm]]

Also, this makes for a nice test case:

https://bugzilla.mozilla.org/attachment.cgi?id=298533

It's a simple page with an animated div contrtolled by setTimeout. On windows, draging something off your links bar will freeze the animation. Then if you drop it back on the bar you'll see a quick burst of animation as all the frozen events get processed.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> Also, this makes for a nice test case:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=298533

Thanks!

This illustrates what I was trying to say very nicely, and (unlike
http://www.vg.no) has the advantage that it won't go away or change.

Comment 17

[Mats Palmgren (inactive)]

The patch in bug 389931 seems to fix this.  Any help with testing that
patch would be appreciated.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This should be fixed now. Marking so.