XtDisplayToApplicationContext fails with "Error: Couldn't find per display information"

[Eirik Byrkjeflot Anonsen]

Glynn Clements <glynn at gclements.plus.com> writes:

> Tristan Schmelcher wrote:
>
>> Hello all. Sorry if this is not the right place to send this, but I'm
>> developing a plugin for Firefox on Linux and I've run up against a
>> roadblock. In my plugin I'm being passed a pointer to an X "Display" struct
>> (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling
>> XtDisplayToApplicationContext on it to get an app context to use in various
>> Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit
>> with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I
>> build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it
>> doesn't work. When it enters XtDisplayToApplicationContext, I get "Error:
>> Couldn't find per display information" on the console and the program exits.
>> 
>> Does anyone know what could be causing this function to fail? I searched the
>> web but without luck.
>
> AFAIK, the display must have been "registered" with Xt via
> XtDisplayInitialize(). With a conventional Xt-based application, this
> is done by e.g. XtAppInitialize().
>
> Firefox isn't an Xt application, so I'm a bit surprised that it works
> at all. However, digging deeper I see that libxul.so uses Xt:

This is a requirement in the netscape plug-in api.  It passes a window
that is documented to be an XmDrawingArea to the plug-in.  However,
most browsers ignore that and uses a plain Xt window instead.
Obviously, the plug-in itself needs some way of accessing the window
and receiving events.  Painting can be done with plain X, but in order
to receive events, the plug-in must register with the browser's main
loop.  So the only reasonable thing to do is to use Xt.  (Yes, the
netscape plug-in api is broken by design.  The windowless style is
slightly less broken, though.)

eirik