Safari browser plug-in only works under debugger...!

[peteatjuce]

Just to confirm:

Open Finder
Select Applications
Right-click on Safari icon you’ll see there
Select Get Info
Check the “Open in 32-bit mode” item
(Re-)start Safari
Run your plug-in test page…
… the plug-in works!

So hopefully that gives you the info you need!

Best wishes,

Pete

[jules]

Ok, at least we now know the problem. If you run safari in 32-bit mode, the plugin works.

Just need to figure out how the hell to work around it then…

[peteatjuce]

For my 2 cents thought, I wonder if the plug-in needs to be build as a 32-bit and 64-bit UB…?

Pete

[jules]

I tried building it as 64-bit, and hit an error telling me that NPAPI can’t be built in 64-bit mode…

[peteatjuce]

OK… next question … do you specifically specific the Cocoa event model, and the CoreGraphics drawing model?

Pete

[jules]

I’ve tried both models…

I’ve now actually persuaded it to compile as 64-bit - it just needed to be using the 10.6 SDK for that. But then when it gets the window handle, which is allegedly an NSWindow*, the damn thing is null!

I give up, this is driving me mad!

[jules]

Ok, I’ve checked in a small update that does now compile as 64-bit and which contains code that should work, but doesn’t because safari passes a null pointer instead of any window information.

Sorry, I’m stumped. Maybe they just don’t want people to use NPAPI plugins any more?

[peteatjuce]

Think how good you’ll feel when you’ve cracked it.

NB: IIRC, if you open Finder
Select Your HD
Then Library
Then Internet Plug-ins
Right-click on the Flash plug-in
Select "Show Contents"
That’ll open the window with info.plist shown
Double-click on the info.plist file

There are two items at the bottom, one called something related to Carbon, with value set to YES … is it LSPrefersCarbon?

I was wondering if that is significant?

HTH

Pete

[peteatjuce]

Found what you’re looking for - I think!

http://lists.apple.com/archives/webkitsdk-dev/2009/Sep/msg00003.html

My experience is that NPP_SetWindow is called, but the window field of the NPWindow struct is NULL. You should use the CGContextRef pass into NPP_HandleEvent (in the draw event struct) for drawing.

https://wiki.mozilla.org/index.php?title=Mac:NPAPI_Event_Models&curid=23772&diff=147156&oldid=147155#The_Cocoa_event_model

Xcode launches Safari as a 32-bit app for some reason, so the plugin works as it did in Leopard.

HTH!

Pete

[jules]

A CGContextRef is useless! There’s no way to find out the window that it’s attached to!

[jules]

BTW the plist idea was a good one, but I tried adding that to the demo plugin’s plist and it didn’t help…

[peteatjuce]

You’re right…!

It looks like in Safari 64-bit, plug-ins are no longer owned by a window; what we’re passed instead is a CGContextRef into which we draw when required.

i.e. the model is a bit different to what went before.

This clarifies where events come from, and how to draw, in this new system:

https://wiki.mozilla.org/index.php?title=Mac:NPAPI_Event_Models&curid=23772&diff=147156&oldid=147155#The_Cocoa_event_model

If a plug-in sets the event model to NPEventModelCocoa, then the following changes are made, each of which is described in detail further in this document:

* NPP_HandleEvent now passes an NPCocoaEvent struct.
* Null events are no longer sent.
* The window field of NPWindow is null. the CGContextRef to use when drawing is a member of the draw event struct. 

All coordinates passed to the plugin via the Cocoa event model are based on the origin being in the top-left (not bottom-left as in standard Cocoa coordinates). This is on account of the fact that the CoreGraphics context given to the plugins is flipped for historical reasons.

HTH!!

Pete

[jules]

Well in that case I was wasting my time trying to fix it. Without being able to embed an NSView this can’t be done with juce.

I guess it means that writing a webkit plugin is the only solution for safari, but I don’t have time to do that in the near future.

[peteatjuce]

Aaargggh…!

OK, well at least we now know exactly what the problem is. Thanks for all your help in tracking this down…

Best wishes,

Pete

[jules]

It sounds like the 64-bit version sandboxes plugins into a separate process, which I guess is why it doesn’t let you embed your own NSView in their GUI.

[peteatjuce]

I wonder if it would be possible to create an NSView… which is hidden/floating … in response to CGContextRef paints, we render to a surface/image in the Juce NSView… and then blit out from their into the CGContextRef. Of course, we’d need to send UI events from the browser plug-in to the NSView to be handled…

Just an idea anyways!

Best wishes,

Pete

[jules]

Sadly not really feasible. Even if it worked, it’d probably be far more trouble than just writing a webkit wrapper.

[peteatjuce]

Do you have any plans for this…

Pete

[jules]

My life seems to be an endless stream of awkward plugin formats… The thought of supporting yet another one doesn’t fill me with joy…

[peteatjuce]

I know how you feel…! :-/