416716 - Support loading plugins asynchronously

Status: RESOLVED DUPLICATE of bug 998863

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

Support loading plugins asynchronously

Mozilla.org programs that can host plugins should be able to load them
asynchronously.  By this I mean the following (at a minimum):

1) When a plugin is loaded asynchronously, it should not be considered
   ready for display (or any other activity) until it calls a callback
   function (in the plugin host) with a status of "now I'm ready".

2) For the time between a when a plugin is asked to load
   (asynchronously) and when it calls the above-mentioned callback to
   say "I'm ready", the plugin host shouldn't issue commands of any
   kind to the plugin -- particularly ones that may cause it to update
   (or try to update) its display.

   An option could be provided to display a static placeholder
   (specified by the plugin) while the plugin is initializing.  But
   there should also be an option to do nothing at all -- even at the
   cost of temporarily displaying garbage.  (One reason for this is
   that plugins may begin displaying before they're fully initialized
   -- as some Java applets do on OS X, notably the NOAA radar applets
   at http://weather.gov.)

I'm the author of the Java Embedding Plugin (bundled with OS X distros
of Mozilla.org browsers).  And my main motivation for this suggestion
is to allow the JEP's initialization of Java applets (and of the JVM
itself) to be simpler and less troublesome (more about this in my next
comment).

But I suspect that other plugins may also benefit from having an
option to load asynchronously, particularly on OS X.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

The JEP's code for loading and initializing Java applets and the JVM
is very complex, and has some unavoidable problems.  Fortunately none
of these problems is a show-stopper.  But they can be quite annoying,
and it'd be nice to be able to resolve them.  This won't be possible
until Mozilla.org browsers allow the JEP to load applets (and the JVM)
asynchronously.

Apple's JVM is initialized (and applets are loaded into it)
asynchronously, on secondary threads (neither Apple's JVM nor any Java
applet are ready for use as soon as the command to load a plugin
returns).

To support synchronous loading (currently the only option), the JEP
needs to spin the main event loop until it thinks the JVM and the
applet being loaded are ready, and only then return from the call to
load a plugin.  But doing this creates problems of its own, for the
following reasons:

1) It's difficult to know which events the JEP should process while
   it's spinning the main event loop.  Should the JEP only process
   system events (what it currently does)?  Should it also process
   some or all Gecko events?  If only some, which ones?

2) Each Java applet must be initialized individually, in sequence.
   But this can lead to severe delays loading pages that contains lots
   of Java applets -- particularly in comparison to a browser that
   (like Safari and all WebKit browsers) loads Java applets
   asynchronously.

I'll talk about specific examples of these problems in my next
comment.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Item #2 from comment #1 has very specific consequences.  As far as I
know, only one bug has been opened that is a consequence of item #2:

bug 311530

Item #1 (from comment #1) has many different kinds of symptoms:

1) Java applets sometimes don't display properly (or at all) when
   they're first loaded.  The workaround is to scroll or resize the
   browser window.

   I don't know of any single bug that addresses this issue directly,
   but it came up in bug 412187 comment #8.

2) The browser can be momentarily unresponsive while a Java applet is
   loading.  This is because the JEP doesn't (and can't) process Gecko
   events while its spinning the main event loop.  (Much nastier
   problems occur if the JEP _does_ try to spin the Gecko event loop.)

   As far as I know, this has never been reported.  But it's quite
   easy to reproduce, particularly with a large Java applet (or one
   loaded over a slow connection), and with the first Java applet to
   be loaded (which also loads the JVM).

3) An oddball assortment of other problems, including some crash bugs.
   I've got workarounds for all the ones that I know about.  But there
   may be others of which I'm not yet aware.

   Here's a list, possibly incomplete:

   bug 309122
   bug 312062
   bug 324281

There's also bug 334905, which concerns the JEP spinning the main
event loop while stopping a Java applet.  So maybe there should also
be options to stop and destroy plugins asynchronously.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

For #1, I think there's bug 401064.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> For #1, I think there's bug 401064.

Yes, that's possible (and thanks for mentioning it, since I'd
forgotten about it).

But for that bug there also seem to be other factors (see bug 401064
comment #2).

Comment 6

[Steven Michaud [:smichaud] (Retired)]

If I remember correctly, we've finally decided to do this, in order to make plugins more manageable in e10s.  Can't find the bug, though.

Of course the JEP is long gone now, so I no longer really have an interest in working on this bug.