I have the latest from git (1.53.58) and a clean compile of the JuceBrowserDemoPlugin will not load in Firefox 4. When I try to load it manually it reports a corrupt file for both 32- and 64-bit builds (aside: in Chrome I can only load 32-bit plugins, and in Safari both seem to work). The result is the same using the slightly older version we currently build with our application.
These are the two messages which appear in the Firefox error console:
The binaries still work, but they’ve changed the xpi format - the directory structure in the xpi needs to be organised differently for it to work in FF4 - not sure exactly what’s needed, but I’m sure there’s info about it out there somewhere…
There’s nothing for me to fix, I’m afraid! The code’s fine, and the actual binaries do still work if you put them into the right place - it’s just the packaging mechanism that Mozilla have mucked about with. I’m staying well clear of any XPI packaging questions though, that’s definitely not my area of expertise!
“the actual binaries do still work” … just wanted to clarify that …?
I can’t even get FF4 to recognise that the plug-in exists … whereas other (old) plug-ins are reported in Firefox, and I’m pretty certain they haven’t been updated…?
Safari reports the plug-ins (but runs only in 32-bit mode of course, see this old forum thread… http://www.rawmaterialsoftware.com/viewtopic.php?f=4&t=4430&hilit=safari&start=30 …)
Blimey, I wish that these companies wouldn’t change things, makes it very difficult for plug-in developers!
Just wondering if this is a 64-bit / Cocoa issue, just like for Safari… https://wiki.mozilla.org/Mac:NPAPI_Event_Models
"The Cocoa event model is an alternative event model for 32-bit Mac OS X plugins and the default event model for 64-bit Mac OS X plugins. "
Edit: just forced Firefox to run in 32-bit mode on Mac - and the plug-in is detected and run.
[To set Firefox to always run in 32 bit mode, open up Finder and go to the Applications folder. Control-click the Firefox app and click “Get Info”, then select the “Open in 32-bit mode” option…]
In firefox it’s pretty likely that just building a 64-bit universal binary will be enough (you can do a 64-bit NPAPI if you target 10.5 (or maybe 10.6… can’t emember exactly). In safari when I lasted looked, the problem was more severe because it wasn’t allowing a 64-bit binary to add its NSView to the window and I couldn’t find a way around that - seemed like the only portable way to do it would be to ditch NSViews and render the pixels directly into its buffer, which would involve some extremely serious changes (not to mention making it impossible to embed things like video).
Just to note this page … https://wiki.mozilla.org/Mac:NPAPI_Event_Models … last edited by somebody by Apple. I’d put money on all the 64-bit Mac browsers using the Cocoa model. FWIW, I’d bet that this is why the plug-ins don’t show under Chrome on Mac … where there is no 32-bit mode the last I looked …
Blimey mate - I don’t envy you at times like these
So has anybody gotten their plugin to compile & load under OSX Firefox 64bit?
I have a plugin that does not draw anything on the screen, so it’s actually working with Safari 64bit. I’m assuming that it would also work in Firefox 64 if i could just get it to be recognized, but FF completely ignores it. When i try to compile it as a 32/64 bit binary i hit the following in npapi.h:
#if defined(XP_MACOSX) && defined(__LP64__)
#error 64-bit Netscape plug-ins are not supported on Mac OS X
#endif