Darin Fisher Reporter
	Description • 18 years ago

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.

	Darin Fisher Reporter
	Comment 1 • 18 years ago

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).

	Mark Mentovai
	Comment 2 • 18 years ago

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

	Håkan Waara
	Comment 3 • 18 years ago

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

	Steven Michaud [:smichaud] (Retired)
	Comment 6 • 17 years ago

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

	Steven Michaud [:smichaud] (Retired)
	Comment 8 • 17 years ago

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.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 9 • 17 years ago

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

	Martijn Wargers (dead)
	Comment 10 • 17 years ago

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

	Recall
	Comment 11 • 17 years ago

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.

	Steven Michaud [:smichaud] (Retired)
	Comment 12 • 17 years ago

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.

	Steven Michaud [:smichaud] (Retired)
	Comment 13 • 17 years ago

(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.)

	Jim Mathies [:jimm]
	Comment 14 • 16 years ago

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.

	Jim Mathies [:jimm]
	Comment 15 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired)
	Comment 16 • 16 years ago

> 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.

	Mats Palmgren (inactive)
	Comment 17 • 16 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 18 • 16 years ago

This should be fixed now. Marking so.