Add support for non X11 unix platforms

• Component: Plug-ins
• Status: RESOLVED DUPLICATE

[Michael Emmel]

Added XP_X11 and XP_DIRECTFB ifdefs and platform support for DirectFB

[Michael Emmel]

Created attachment 20702 [details]
Add Platform definiontion and ifdefs for DirectFB add X11 specific def


This is probably a bit controversial since I went the route of adding XP_X11
but it makes the most sense and follows the logic WebKit took for multiple graphics stacks and operating systems.

[Michael Emmel]

Created attachment 20705 [details]
Add changelog entry to original patch

[Eric Seidel (no email)]

Comment on attachment 20705 [details]
Add changelog entry to original patch

Looks fine to me.

[Darin Adler]

Comment on attachment 20705 [details]
Add changelog entry to original patch

I'm not sure this patch is OK to land.

It seems to change the npapi.h header so that it requires a new symbol, XP_X11 to be set to make it work as it did before. What is going to set that symbol outside the WebKit project?

[Michael Emmel]

This would result in a proposed change to the plugin header that would need to be propagated back to Mozilla.

I'd argue that its needed even in the case of Mozilla which is supported on gtk/directfb.

I don't know who is responsible for the interaction between Mozilla and WebKit.

[Mark Rowe (bdash)]

Comment on attachment 20705 [details]
Add changelog entry to original patch

Setting as r- per Darin's concerns in Comment #4.  We can't make changes like this to an API header file without them being discussed with Mozilla first.

[Sriram Neelakandan]

Mozilla has already made some changes along these line to ensure inclusion of X11 headers under MOZ_X11; 

Please see the latest file here on the NPAPI SDK link that i found on the plugin-futures wiki page (https://wiki.mozilla.org/NPAPI#NPAPI_SDK)

The Latest NPAPI Header as per Mozilla's NPAPI SDK
http://code.google.com/p/npapi-sdk/source/browse/trunk/headers/npapi.h

And this dates back to r2 on the Version trunk which already had MOZ_X11 protection flags

http://code.google.com/p/npapi-sdk/source/diff?spec=svn2&r=2&format=side&path=/trunk/headers/npapi.h

Interesting fact is the first version import of the NPAPI header has 
npapi.h:104	#define NP_VERSION_MINOR 27

where as webkit trunk is @
npapi.h:103	#define NP_VERSION_MINOR 24

So is there a policy on how often Webkit updates NPAPI headers ?
Or should i just pull that file from npapi-SDK and submit as a patch for review ?

[Eric Seidel (no email)]

I'm not sure who the right plugin people are for NPAPI these days, but not me. :)

[Stuart Morgan]

(In reply to comment #7)
> So is there a policy on how often Webkit updates NPAPI headers ?
> Or should i just pull that file from npapi-SDK and submit as a patch for review ?

The reason you see divergence is that the npapi-sdk project is quite new in the history of NPAPI; until recently, there was no single source, and each browser vendor had their own copies of the headers that had diverged a fair amount. Work has been done to bring WebKit much closer to the new upstream header, but it was never finished (see bug 38666, bug 77200, and the various bugs they reference).

I'd recommend strongly against trying to check in the upstream headers directly as a single patch, and instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.

[Michael Emmel]

(In reply to comment #9)
> (In reply to comment #7)
> > So is there a policy on how often Webkit updates NPAPI headers ?
> > Or should i just pull that file from npapi-SDK and submit as a patch for review ?
> 
> The reason you see divergence is that the npapi-sdk project is quite new in the history of NPAPI; until recently, there was no single source, and each browser vendor had their own copies of the headers that had diverged a fair amount. Work has been done to bring WebKit much closer to the new upstream header, but it was never finished (see bug 38666, bug 77200, and the various bugs they reference).
> 
> I'd recommend strongly against trying to check in the upstream headers directly as a single patch, and instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.

But why have platform types in this header ? They can readily be moved to a included platform header along with platform specific entry points. 

The EGL bindings do a fairly good job of isolating platform types and can server as a template.

Where needed you have NativeDisplay. NativeWindow etc.

On top of this both WebKit and Mozilla have and extensive porting layer very few plugins actually need direct access to the underlying platform.  Exporting the porting layer as a target for plugins suffices for 90% or more of the plugins. Flash for example could be trivially ported to both browsers porting layers.

With HTML 5 the api is effectively complete in the porting layer.


This is perhaps going beyond this bug report. But recognize the need of and api for native extensions that makes far more sense then the current plugin concept. Almost all plugins should be ported to a new native extension api synchronized between browsers.  A small number will need to bypass this.

[Sriram Neelakandan]

(In reply to comment #9)
>  instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.

Then as a first step;
I am preparing a patch which will have the MOZ_X11 changes against npapi-sdk@r14 for webkit's npapi.h, add upload the patch to bug#40785

Does that sound right ?

[Sriram Neelakandan]

I guess this can be marked dup of https://bugs.webkit.org/show_bug.cgi?id=40785

[Martin Robinson]

I don't think we are interested in DirectFB any longer, but Wayland support is still an issue.

*** This bug has been marked as a duplicate of bug 81456 ***