Chrome for Mac (which currently can only load 32-bit plugins) stopped supporting Carbon event model plugins in version 22, and Firefox has dropped Carbon event model support on trunk already for Firefox 19 (https://bugzilla.mozilla.org/show_bug.cgi?id=598397), which means a JUCE-built plugin won’t work in Mac Chrome, and soon won’t work in 32-bit Mac Firefox. For best compatibility JUCE should always use the Cocoa event model if it’s available, or at the very least in any browser where the Carbon model is not available (both of which can be checked at runtime via an NPAPI call). This would give wider 32-bit support, most notably allowing plugins to work in current versions of Chrome. It would mean that people wouldn’t be obligated to ship hybrid 32-bit/64-bit plugins, because the 64-bit Mac browsers are all capable of loading 32-bit Cocoa event model plugins.

(FYI, the current event model negotiation isn’t doing anything; by spec, Carbon is the default in 32-bit, and Cocoa is the default in 64-bit, so all the current JUCE code is doing in both 32- and 64-bit is explicitly setting the mode that would be assumed anyway.)

Hmmm… looking at the bleeding edge release, i think you already did it:

“#if JUCE_USE_NPAPI_CARBON_UI”

So if its not defined (which its not), it should take the cocoa event model if I understand correctly. However, the plugin still doesn’t work under chrome on the mac (10.7). Do you have any idea Jules, is this related to the event model ? (should I create a new thread for this?)