Re: [firebreath-dev] Newbie Questions

[John Dexter]

Here, but be prepared to be told to RTFM (in the nicest possible way) if you don't show evidence you have looked at the docs and samples ;)

It's a friendly bunch though.

On 16 April 2013 23:03, Michael Jennings <mike.c....@gmail.com> wrote:

Hi,

I've just started playing around with FireBreath and plugins and want to know the best place to ask total newbie questions.

Thanks!

-Mike

--
 
---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Taran Rampersad]

Here's the best spot, but... make sure you read the docs. Also, suggest
that you build the examples too so that you become familiar with the
process.

Michael Jennings wrote:
> Hi,
>
> I've just started playing around with FireBreath and plugins and want
> to know the best place to ask total newbie questions.
>
> Thanks!
> -Mike
>

--

Taran Rampersad

[Michael Jennings]

Well I can already tell it's a friendly bunch :)

Thanks so much for responding so quickly!

My question is more plugin than FireBreath specific, but from what I've seen on the web, the author of FireBreath is probably the world's foremost expert on plugins, so here goes;

I have a simple NPAPI example from Apple, i can build a .plugin, and i can manually install it, but I'm having trouble telling XCode "build for debug, install it, then launch Safari and stop at a breakpoint" in one fell swoop. Is there a good tutorial for doing that?

Thanks in advance for any suggestions!

[Richard Bateman]

"world's foremost expert" would be a gross exaggeration, but you'll find a lot of plugin experience on this list. You could also try stackoverflow.com with the npapi tag.

Unfortunately, I gave up on trying to make Xcode do what you describe a long time ago. If you look in the np_macmain.cpp file in the firebreath codebase (I think it's in PluginAuto) you'll see some code that pauses until a debugger is connected; that's what I use. I then launch the plugin in a browser (usually Chrome or Firefox) and attach the debugger to the plugin process, after which my breakpoints work and the plugin finishes starting up.

The problem with Safari is that they seem to have added a watchdog timer that is fairly short; if your plugin doesn't respond within the set time (seems like it was 15 or 30 seconds or some such) it will simply kill your plugin process out of hand. The reason this is such a big problem is that if your plugin is being debugged / stopped at a breakpoint and you're stepping through code then your plugin process isn't responding and the browser will likely kill it before you get very far. For this reason I nearly always debug using chrome or firefox.

Make sure you're familiar with the Debugging Plugins page on the website as well; lots of good info there.

Richard a.k.a. taxilian

[Michael Jennings]

Thanks for getting back to me Richard!

I don't think what I said is an exaggeration at all, but glad to know you don't have an ego >= your ability.

So the "attach to process" is the only way to go for Xcode eh? Drag.

By the way, I stumbled across this:

"defaults write com.apple.Safari DisablePluginProcessMessageTimeout YES"

which supposedly stops Safari from killing plugins that are being debugged (ie stopped in a debugger). I haven't tried it out yet though.

I'll let you know if I find anything useful out.

-Mike

[Richard Bateman]

That is extremely useful info! Could you throw that up on the Debugging Plugins page on the wiki?

Richard

Apr 17, 2013, в 11:44, Michael Jennings <mike.c....@gmail.com> написал(а):

[Michael Jennings]

Absolutely, once I can verify that it does something. Right now I can't get XCode to hit a breakpoint in my plugin :(

I think the "Debugging Plugins" page refers to a version of XCode that is newer or older than the one I have (I think I have the latest, I think).

[Richard Bateman]

Make sure that you're connecting to the correct process!

Richard

Apr 17, 2013, в 16:32, Michael Jennings <mike.c....@gmail.com> написал(а):

[Michael Jennings]

Yes, it is. When I go to the "attach to process" menu in XCode, it list the bajillion processes I have running, and for Safari.app it says "already attached". Furthermore, I can hit "pause" in the XCode debugger and it stops Safari dead. So I'm pretty sure it's the Safari.app that it's debugging.

Oh, also, I've figured out (amongst the annoying multitude of knobs that XCode lets me twiddle) how to get XCode to:

a) run a script after successful build

b) Fire up Safari.app and attach to it to Debug (this is done via "Schemes" and other non-intuitive stuff)

My script copies the .plugin from the "Debug" location (I have it set to something like $(PROJECT_DIR)/Build/Debug) to ~/Library/Internet Plugins since my assumption is that breakpoints only work for something that is compiled for "Debug"

But no debug breakpoints seem to work alas. I'm working with a project I downloaded from Apple called "NPAPI_Core_Animation_Movie_Plugin"

I wanted to get a go-cart working before playing around too much with the Lexus that FireBreath is. Also, the NPAPI_Core_Animation_Movie_Plugin is a dirt-simple plugin, so anything that goes wrong with it has nothing to do with misuse of Boost, CMake and other powerful tools that FireBreath uses.

One other thing, the project I downloaded includes a test.html and when the plugin is correctly installed, the plugin does indeed work.

I'm sure it's some stupid setting I'm missing. Sigh.

[Richard Bateman]

See, that's exactly what I was worried about.  You don't *want* to be debugging Safari.app. Doing a quick search of my processes while running a plugin in Safari it looks like the name of hte executable where the plugin is actually running is called "PluginProcess" (at least in Safari 6.0.3). Plugins run "out of process", meaning that they actually run in a different process; if you're connected to Safari, you're not connected to the right process!

Richard

Apr 17, 2013, в 21:05, Michael Jennings <mike.c....@gmail.com> написал(а):

[Michael Jennings]

D'Oh! Y'know, I actually did read about the "out of process" thing, then I guess my brain thought I was debugging DLLs in the mid-90's. Sigh. Sometimes it feels like my brain is past its "best before date".

Thanks Richard. I'll post any progress I make.

[Michael Jennings]

So I was able to step through my dirt-simple plugin with XCode, huzzah! All I needed to do was connect to "PluginProcess". Also, Safari didn't time out and kill the process, so I guess that magic "defaults write" thing worked!

If you get a spare moment in your life, could you verify on your end? I don't want to be giving out false information (also, I trust your plugin debugging more than my own).

I'm wondering now, since there is a special secret-sauce "hidden" setting to tell Safari not to kill PluginProcess if it takes too long, obviously that is there for the coding convenience of Apple engineers. I wonder what else is there for the benefit of those "in the know"? Perhaps a magic setting to actually run plugins in the Safari process? What would you do if you were an Apple engineer working on the Quicktime plugin?

[John Tan]

The tough part about developing plugin for mac is that it is windowless. The drawing is primitive. Someone mentioned that wxwidgets should work but I've yet to see how.