Re: Problem with stopModalWithCode on a different thread
Re: Problem with stopModalWithCode on a different thread
- Subject: Re: Problem with stopModalWithCode on a different thread
- From: Bill Appleton <email@hidden>
- Date: Tue, 22 Jun 2010 13:58:41 -0700
Hi Charles,
Under Safari 64 bit you HAVE to use Cocoa -- there ain't nuthin' else.
By the way i just found out that this problem is FIXED in the latest version
of Safari.
Thanks all,
bill
On Tue, Jun 22, 2010 at 1:10 PM, Charles Srstka <email@hidden>wrote:
> On Jun 22, 2010, at 1:54 PM, Bill Appleton wrote:
>
> > Hi all,
> >
> > Thanks for the tips.
> >
> > i have verified that this code actually IS running on the main thread, i
> was wrong about that in my original message. Here is the situation. WebKit
> launches WebKitPluginHost.app and that is the process that runs my NPAPI
> plugin. The plugin is called on the main thread, and NSApp is already
> initialized. However I can absolutely confirm this bug is happening, I
> logged a webkit bug on it, no telling what will happen with that.
> >
> > i was able to fix this problem in my dialogs (not system dialogs) by just
> saving the clicked button in a global and calling abortModal, then i just
> return the global & it works perfectly. So Charles, your tip about "write
> your own method that wraps stopModalWithCode" is probably the practical way
> to fix this. But I can't subclass NSApp (it is already initialized) & I'm
> having trouble figuring out how to write a method that can just intercept a
> class message in general. Is that possible?
>
> Wait a minute - why are you using NSApp in an NPAPI plug-in? NPAPI plug-ins
> could be loaded into a non-Cocoa browser such as Firefox that will not have
> an NSApp set, so this seems inadvisable (and could possibly be part of what
> is causing the weird behavior you’re seeing).
>
> Apple seems to suggest that this sort of thing should not be done in an
> NPAPI plugin:
>
>
> http://developer.apple.com/mac/library/documentation/InternetWeb/Conceptual/WebKit_PluginProgTopic/Tasks/NetscapePlugins.html#//apple_ref/doc/uid/30001250-DontLinkElementID_1
>
> > • Use platform APIs sparingly. Wherever possible, you should use
> new plug-in APIs to do what you need. If no such APIs exist, file bugs
> requesting them.
> > The plug-in API provides additional APIs for scheduling timers, opening
> contextual pop-up menus, and so on.
> > Note: Calls to browser scripting functions work normally. WebKit
> transparently handles the interprocess communication for you.
> > • Avoid creating windows. The intent is for plug-ins to operate
> within the browser window. Although some plug-ins have historically done so,
> creating windows in your plug-in is not recommended. If you need to maintain
> separate windows, you should consider starting a separate application.
>
> Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden