84568 - [Xlib] xlib port does not support netscape plugins

Status: VERIFIED FIXED

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

Description

[pocemit]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [ja] (X11; U; Linux 2.4.4 i586; Nav)
BuildID:    20000608

unimplemented plugin support

Reproducible: Always
Steps to Reproduce:
1. go to some page with Flash for example


Actual Results:  crash

Expected Results:  flash stuff should load

Patch in the next attachment

Comment 1

[pocemit]

reassigning to myself, adding to xlib tracker bug

Comment 2

[pocemit]

Attachment: Adds support for plugins to Xlib port

Comment 3

[pocemit]

can I do this?

Comment 4

[pocemit]

Attachment: Slightly improved patch

Comment 5

[Peter Lubczynski]

I'm not qualified to review this patch, but you probably want module owner
Andrei Volkov's approval.

cc:ing Serge and Dan for possible reviews....

Comment 6

[pocemit]

Attachment: Final version of the plugin patch, with changes from bug 55278

Comment 7

[av (gone)]

Looks like all the code in the plugins area is nicely ifdefed for 
MOZ_WIDGET_XLIB, I don't immediately see any problems but would really like our 
Linux guru to take a look. Serge?

Comment 8

[pocemit]

The only problem with this is you can't compile GTK and Xlib port at the same
time. I personally dont see this as a problem, but there is a (old, probably
rejects) solution to this (includes making a new directory) in bug 55278.

Comment 9

[serge (gone)]

How can I build Xlib port? 
I assume ./configure --enable-toolkit=xlib should work, and than rebuild 
everything or can I do particular gmake in widget/src/xlib, module/plugins ...? 

Comment 10

[pocemit]

To make xlib port usable you first need to apply the last patchset from bug 66082.
There are also instructions for compiling Xlib port in the same bug.
Bug 79119 is a general xlib tracking bug which has all the other xlib related
issues.

Comment 11

[serge (gone)]

Thanks, I've built it, tested it, it works fine, so r=serge.
But it's getting difficult to read and maintain ns4xPluginInstance.cpp with all 
those #ifdefs:(  
Andrei what do you think about braking out this .cpp by different widget's set?

Comment 12

[pocemit]

Can this discussion be resumed (splitting nsPluginHostImpl into toolkit
dependent portions)?
What is required to accomplish this?
Both Xlib and QT ports don't "really" support plugins right now, and with these
patches legacy plugins work ok under xlib but as you say, it's #ifdef'd and gets
rather ugly.

So if tehre is anything I can help with as far as splitting this off and
integrating toolkit-specific changes, please let me know.

Comment 13

[Roland Mainz]

pocemit:
Wanna file a new patch for review, please ? The old one does not "apply"
properly anymore (gpatch warnings)...
I'd like to get this "in" ASAP and discuss the remaining issues later, if
possible...

Comment 14

[Roland Mainz]

timeless:
Can I overtake this bug, please ?

Comment 15

[pocemit]

hey gisburn... just checking my mail while on vacation,
feel free to fix plugins.. they work...
but according to the people here we should split the plugin stuff by platform..
enjoy.

Comment 16

[Roland Mainz]

Accepting bug, setting milestone...

Comment 17

[Roland Mainz]

Attachment: Patch for 2001-07-16-08-trunk

Comment 18

[Roland Mainz]

Filed new patch.
Xlib-toolkit Zilla now loads the plugins and displays them... buut leaving the
page ends-up in the following X error:
-- snip --
Inside nsPluginHostImpl::FindStoppedPluginForURL...
For application/x-shockwave-flash found plugin
/home/mozilla/builds/2001-07-16-08-trunk/objdir_ws6_xlib/dist/bin/./plugins/libflashplayer.so
Inside ns4xPluginInstance::Start(void)...
Inside ns4xPluginInstance::SetWindow(b80b20)...
About to create new ws_info...
About to create new xtbin of 200 X 1200 from 07c00487...
About to show xtbin(b71368)...
About to call CallNPP_SetWindowProc()...
Falling out of ns4xPluginInstance::SetWindow()...
created stream for
http://www.macromedia.com/uber/nav/rnav/l_rnav_1200px.swf?source=/software/flash/rnav_fl_main.txt
InstantiateEmbededPlugin.. returning
Inside ns4xPluginInstance::SetWindow(b80b20)...
About to call CallNPP_SetWindowProc()...
Falling out of ns4xPluginInstance::SetWindow()...
Inside ns4xPluginInstance::SetWindow(b80b20)...
About to create new ws_info...
About to create new xtbin of 200 X 1200 from 07c00487...
About to show xtbin(b71368)...
About to call CallNPP_SetWindowProc()...
Falling out of ns4xPluginInstance::SetWindow()...
###!!! ASSERTION: oops.. bad flags: 'entry->IsAllowedInMemory()', file
../../../../../../src/2001-07-16-08-trunk/mozilla/netwerk/cache/src/nsCacheService.cpp,
line 939
killing stream for
http://www.macromedia.com/uber/nav/rnav/l_rnav_1200px.swf?source=/software/flash/rnav_fl_main.txt
created stream for http://www.macromedia.com/uber/nav/rnav/rnav_1200px.swf
###!!! ASSERTION: oops.. bad flags: 'entry->IsAllowedInMemory()', file
../../../../../../src/2001-07-16-08-trunk/mozilla/netwerk/cache/src/nsCacheService.cpp,
line 939
###!!! ASSERTION: oops.. bad flags: 'entry->IsAllowedInMemory()', file
../../../../../../src/2001-07-16-08-trunk/mozilla/netwerk/cache/src/nsCacheService.cpp,
line 939
killing stream for http://www.macromedia.com/uber/spotlight/fl.swf
killing stream for
http://www.macromedia.com/software/flash/spotlight_fl_main.swf
###!!! ASSERTION: oops.. bad flags: 'entry->IsAllowedInMemory()', file
../../../../../../src/2001-07-16-08-trunk/mozilla/netwerk/cache/src/nsCacheService.cpp,
line 939
killing stream for http://www.macromedia.com/uber/nav/rnav/rnav_1200px.swf
created stream for http://www.macromedia.com/software/flash/rnav_fl_main.txt
###!!! ASSERTION: oops.. bad flags: 'entry->IsAllowedInMemory()', file
../../../../../../src/2001-07-16-08-trunk/mozilla/netwerk/cache/src/nsCacheService.cpp,
line 939
killing stream for http://www.macromedia.com/software/flash/rnav_fl_main.txt
Disabling Quirk StyleSheet
Enabling Quirk StyleSheet
/software/flash/
/software/flash/contents.html
Inside ns4xPluginInstance::SetWindow(0)...
ns4xPluginInstance::Stop()
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  131 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Resource id in failed request:  0x7c003e5
  Serial number of failed request:  13021
  Current serial number in output stream:  13021
-- snip --

Any ideas ?

Comment 19

[pocemit]

I am taking xlib plugin bugs

Comment 20

[pocemit]

Attachment: patch to fix rejects in latest cvs

Comment 21

[pocemit]

okay, yay...
This makes plugins work, more or less.
This is the best we (?) can do unless plugin code is split by toolkit.
really.
can I get this reviewed?

Comment 22

[chris hofmann]

this is late for 0.9.4.  moving to 0.9.5.  let me know if this is wrong. thanks
-chofmann

Comment 23

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 24

[Roland Mainz]

Stealing from pocemit ...

Comment 25

[Roland Mainz]

Accepting ...

Comment 26

[Roland Mainz]

Attachment: Patch for 2001-11-30-08-trunk

Comment 27

[Roland Mainz]

Requesting r=/sr= ...

Comment 28

[Roland Mainz]

Attachment: New patch for 2001-11-30-08-trunk (minor update)

Comment 29

[Patrick C. Beard]

Comment on attachment 60566 [details] [diff] [review]
New patch for 2001-11-30-08-trunk (minor update)

Couldn't the repeated line:
+EXTRA_DSO_LDOPTS += -lxlibxtbin -lxlibrgb -L/usr/X11R6/lib -lXt
come after the line:
+endif		#MOZ_MONOLITHIC_TOOLKIT

modulo that, sr=beard

Comment 30

[Roland Mainz]

Patch checked in ...

Comment 31

[Peter Lubczynski]

Serge said he saw some weird stuff going on with the new SDK samples last week
with this patch. Serge, is that still the case?

Comment 32

[Roland Mainz]

AFAIK everything is |#ifdef|'ed in a per toolkit basis.

Note that you cannot get working plugin support for the non-GTK+ toolkits if you
build more than one toolkit in one objdir. Please use seperate objdir's (one per
toolkit) instead ...

Comment 33

[serge (gone)]

Yeah, I've seen some random crashes when I've built xlib port on top of gtk one,
but with clean xlib build I haven't seen those crashes anymore.
I'll continue to test SDK samples on both gtk & xlib widget sets,
and, of course, I'll let your know if something goes wrong.

Comment 34

[Roland Mainz]

[e-mail]:
> Yeah, I've seen some random crashes when I've built xlib port on top of gtk 
> one, but with clean xlib build I haven't seen those crashes anymore.

If you take a look at the patch you will see what is going wrong (or simply read
your own comment #11 here :-)
-- snip --
@@ -2511,6 +2513,8 @@
     *value = GDK_DISPLAY();
 #elif defined(MOZ_WIDGET_QT)
     *value = qt_xdisplay();
+#elif defined(MOZ_WIDGET_XLIB)
+    *value = xxlib_rgb_get_display(xxlib_find_handle(XXLIBRGB_DEFAULT_HANDLE));
 #endif
-- snip --

Unfortunately there is no XPCOM service to obtain |Display *| in a
toolkit-independent way. This may be a better solution than trying to split the
plugin sources up into independent pieces for each toolkit ...

> I'll continue to test SDK samples on both gtk & xlib widget sets,
> and, of course, I'll let your know if something goes wrong.

Thanks!

Comment 35

[Roland Mainz]

[e-mail]:
Could you please test printing, too ?
I am having problem with the following sequence:
1. browse a page like http://www.mozilla.org/start/
2. print this page
3. go to a page which contains a plugin like http://www.yahoo.de/
Mozilla hangs in step [3] ...

Comment 36

[shrirang khanzode]

never heard from anyone on this, marking verif.