53507 - nsIPluginInstance::SetWindow hides xwindow handle

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[s.schaefer]

The  structure passed to a plugin by nsIPluginInstance::SetWindow does not
contain a valid xwindow handle (UNIX). Instead the window member of the passed
nsPluginWindow points to a "GdkSuperWin" object which contains a "GdkWindow"
(bin_window) which holds the required xwindow handle to the plugin window. At
least this should be documented, but then it requires using internal Mozilla
structures in the plug-in code which should be avoided.

Comment 1

[Dawn Endico]

marking new and cc-ing architecture weenies

Comment 2

[karnaze (gone)]

Moving to m1.0 and reassigning to peterl.

Comment 3

[Peter Lubczynski]

Is this an envangelism issue or is there a problem in our implementation? 

Have you read the new plugin API guide under Developer Docs on mozilla.org?

Nominating WONTFIX

Comment 4

[Peter Lubczynski]

---> envangelism

Comment 5

[Blake Ross]

Reassigning evangelism bugs to [e-mail].

Comment 6

[Bob Clary [:bc] (inactive)]

Arun, I'm giving you all the Linux bugs. If these bugs can be confirmed for
other OS's please (someone) change the Platform/OS to All/All and reassign to
the default Evangelism Component Owner.

Comment 7

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 8

[Bob Clary [:bc] (inactive)]

Arun, I am taking your Linux bugs minus banks. Hope you don't mind.

Comment 9

[Bob Clary [:bc] (inactive)]

back to Arun for plugin bugs

Comment 10

[Bob Clary [:bc] (inactive)]

-> Plugins

Comment 11

[Arun Ranganathan]

Frankly, I'm confused.  What exactly is the evangelism issue? Can someone step
in and clarify?

Comment 12

[timeless]

back to browser plugins. If you guys feel your documentation is good enough (it 
isn't) then you may reasign this bug to the doucmentation product for them to 
rewrite it.

IMO your documentation isn't clear at all, I can't even follow lxr pointers 
(idl and header only) to find out that it's a gdk*.

Comment 13

[av (gone)]

-->serge

Comment 14

[rubydoo123]

I have asked Ian to make sure this gets addressed in the updated referene manual.

Comment 15

[Ian Oeschger (gone)]

Yes. I will put something in the docs about this. In fact, I'll write something
up and post it here to make sure I've got it right, then I'll go into the
plug-in guide about it.

Comment 16

[Ian Oeschger (gone)]

I've added this to the notes for NPP_SetWindow. It's nearly verbatim from
s.schaefer's first comment here:

"On Unix, the structure passed by NPP_SetWindow does not contain a valid xwindow
handle. Instead the window member points to a "GdkSuperWin" object, which
contains a "GdkWindow" (bin_window), which in turn holds the required xwindow
handle to the plugin window."

Does this suffice?

Comment 17

[serge (gone)]

I don't understand what's this bug about.
yes at the beginning of ns4xPluginInstance::SetWindow(nsPluginWindow* window) 
window->window is not a valid xwindow handle, but we assign it later
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/ns4xPluginInstance
.cpp#896
so on Unix, the structure passed to NPP_SetWindow *DOES* contain a valid 
xwindow.
Why we should docummented nsIPluginInstance::SetWindow() call?

Comment 18

[s.schaefer]

The bug description stems back from the Mozilla Milestone M18 or something.
Meanwhile the problem is gone and the correct structures are passed to the
plugin. No further action required.

Comment 19

[rubydoo123]

based on user comment, marking as verified