David Benjamin
David Benjamin
Older generations of browsers would run plugins in-process, so the wrapper would try to avoid crashing when the viewer did, as a nasty hack. Nowadays this logic is unnecessary as...
The current direct execution stuff is really a mess. Clean up the code a bit so that it may be used as a generic NPAPI tracing utility. The setting probably...
We're almost there but still missing a few new additions. Though some of them may not even be implemented by anyone yet. https://wiki.mozilla.org/NPAPI:AdvancedKeyHandling https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling https://wiki.mozilla.org/NPAPI:ClearSiteData
Not yet sure what's going on, and it's not completely reproducible. There does appear to be a race involved; the viewer is waiting for an SYNC_ACK to begin its event...
It's possible this is actually a QtWebKit bug (this bug has similar symptoms but is fixed https://bugs.webkit.org/show_bug.cgi?id=25053 ). The first Flash video loaded does not isplay and instead you get...
This issue mostly exists to keep the milestone from auto-closing.
This really should be bug #1. This project is disturbing and really shouldn't exist. All remotely reasonable use cases will be handled when Chromium and Mozilla support 32-bit out-of-process plugins....
Not really all too useful but we may be able to avoid making assumptions about the underlying main loop by using NPN_PluginThreadAsyncCall and pushing our event loop on a side...
The original logic is flimsy and distribution patches aren't that much better. Instead, replace with a policy-less C tool which management scripts (probably initially written by distributions) can call.
We probably should make them so, even though NPN_PluginThreadAsyncCall is the only thing that could be helped. In particular, the indent level wants to be thread-local storage and everything else...