Generating async Javascript events from browser plugin (NPAPI)
Asked Answered
U

1

8

I'm writing a web browser plugin (NPAPI.)

My plugin starts a worker thread, and as the worker progresses, I'd like to pass events back to Javascript. But because of the NPAPI threading model, it's not legal for the worker thread to call back into NPAPI directly, so the worker thread can't invoke Javascript.

One solution to this is the NPN_PluginThreadAsyncCall function. But this is a relatively new function. For example, it's supported only from Firefox 3 on.

Is there any way to get async event delivery/javascript execution from an NPAPI plugin without using NPN_PluginThreadAsyncCall? What did people do before this function was added?

Unfair answered 19/12, 2009 at 3:48 Comment(0)
C
5

The answer is yes... and no...

If you need to support older browsers (pre firefox 3), you can implement the NPN_PluginThreadAsyncCall function yourself. On windows, you can do that by creating a data structure that can hold the function pointer and the void* opaque pointer, and then post a custom message to the main window with a pointer to your data structure as the LPARAM.

The main window WINPPROC runs on the UI thread, which is the thread that can talk to Javascript. So, when you get that message in your WINPROC, you simply cast the LPARAM back to the pointer, call the method with the opaque data, and then free the data structure.

On Mac, you can do a similar thing with a queue to store the events in, and then on the NULL event (which gets sent by Mac OS about every tick) check to see if anything is in it. If so, pop it off, call the method, free it, and keep going.

There is probably a way to do it on linux as well, but I don't know what it is.

You can find an example of the windows version in the firebreath project.

The handling of the winproc message is in this file: https://github.com/firebreath/FireBreath/blob/master/src/PluginWindow/Win/PluginWindowWin.cpp

The event and data structure are defined in its header file: https://github.com/firebreath/FireBreath/blob/master/src/PluginWindow/Win/PluginWindowWin.h

And the method for firing that event is here:

void ActiveXBrowserHost::ScheduleAsyncCall(void (*func)(void *), void *userData)
{
    if (m_hWnd != NULL) 
        ::PostMessage(m_hWnd, WM_ASYNCTHREADINVOKE, NULL, 
            (LPARAM)new FB::WINDOWS_ASYNC_EVENT(func, userData));
}
Character answered 20/12, 2009 at 7:17 Comment(2)
Thank you! It is extremely helpful to know that the platform GUI event loop thread is safe for NPAPI calls. And I'll definitely check out Firebreath. FWIW, on Mac, if you can depend on Cocoa, an easy way to run code on the GUI thread is the NSObject method performSelectorOnMainThread.Unfair
Yeah, I think someone told me about performSelectorOnMainThread, but I haven't needed to use it so far. The percentage of users still on firefox 2 is so small these days that I just decided not to support it anymore. With FireBreath, we could add support if someone needed it badly enough (or they could), but I don't need it for any of my stuff. =] There are several really nice features that weren't implemented until firefox 2; NPN_Enumerate and NPN_Construct, for example. Also, firefox 2 has a known bug that it can't see plugins registered in HKCU in windows, so you have to be admin.Character

© 2022 - 2024 — McMap. All rights reserved.