369791 - Make plugins work with cairo-os2

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Peter Weilbacher]

The checkin I just made for Thebes on OS/2 (bug 333235) probably completely broke plugins, but was necessary for now to get it to compile.

Once other aspects are working better we need to add real code to layout/generic/nsObjectFrame.cpp for cairo-os2.

Comment 1

[Dave Yeo]

At this point plugins are working fine here on a trunk pull of June 25th (Firefox). Only thing that is different is Java's dependency on ipluginw.dll seems to be gone now, eg Java works as well as ever without installing ipluginw.

Comment 2

[Peter Weilbacher]

Indeed, the demos for Heiko's GBM plugin module
http://heikon.home.tlink.de/frames/gbm_plugin_mozilla_test_embed.html
http://heikon.home.tlink.de/images/gbm_plugin_mozilla_test.tif
work just fine.

But Java doesn't and Flash doesn't, either. I tried the Innotek Java plugin on
http://www.javatester.org/version.html
and just get "Browser has Java disabled". Flash on 
http://www.adobe.com/shockwave/welcome/
doesn't display anything. But in both cases I would have expected an unpainted empty box, but instead I seem to be getting the alternative "content".

But then I wonder what the code in nsObjectFrame::PaintPlugin at
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsObjectFrame.cpp&rev=1.581#1105
was good for... Well, perhaps we should try our luck on updating IPluginW first.

Comment 3

[Dave Yeo]

I just installed ipluginw.dll to components and for the hell of it plugins, deleted compreg.dat from my profile and started Seamonkey (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a8pre) Gecko/2007090821 SeaMonkey/2.0a1pre) and both the javatester and adobe site are working here. Hmm, after switching tabs the flash test no longer responds to the mouse over though reloading it does start it working again. Even has sound.
No messages at the bottom of the browser about starting java.
Only other thing is I also have eseamonkey running and went to the Java page first with that.

Comment 4

[Dave Yeo]

Removed ipluginw.dll from plugins, plugins still work.
Attaching screen shots

Comment 5

[Dave Yeo]

Attachment: Screenshot of flash plugin working

Screen shot of Flash plugin working on trunk

Comment 6

[Dave Yeo]

Attachment: java test page

Java plugin working on trunk

Comment 7

[Peter Weilbacher]

Attachment: try1

First cut at a patch to implement the piece of code that I commented out in nsObjectFrame.cpp. It compiles and links with the patch. But it doesn't change anything here at all, the region on http://www.javatester.org/version.html where the version is supposed to appear remains empty. Didn't try to debug it at all yet.

Comment 8

[Peter Weilbacher]

Oops, forgot ipluginw again:

- without patch, without ipluginw: Java doesn't display
- without patch, with ipluginw:    Java displays version
- with patch,    without ipluginw: Java doesn't display
- with patch,    with ipluginw:    Java displays version

This is with a Firefox debug build. (Weird, because for my normal SeaMonkey build ipluginw doesn't make a difference...)

Comment 9

[Peter Weilbacher]

(In reply to comment #8)
> (Weird, because for my normal SeaMonkey build ipluginw doesn't make a difference...)

Forget that, too. I apparently didn't remove compreg.dat in the SeaMonkey profile after copying ipluginw.dll into components. It works fine.

It doesn't print, though, and the patch here doesn't change that.

Comment 10

[Peter Weilbacher]

Comment on attachment 301596 [details] [diff] [review]
try1

OK, I now added some debug output to the functions in question -- nsObjectFrame::PaintPlugin() and nsPluginInstanceOwner::Paint() -- and tried all the plugins I have (Innotek Java 1.4.2_09, Flash 7.x, NPGBM 1.32) on a few different pages but I didn't see that output appearing. With ipluginw.dll added all of them work, without it none do.

Will try to add print support and upload a new patch which we can then check in (or not).

Comment 11

[Peter Weilbacher]

Attachment: try2

OK, so this adds the missing plugin painting code for OS/2 as in try1 (that still doesn't get called for any of my plugins) and support for printing of plugins. The latter works for the NPGBM plugin but not for Flash or Java. GoldenCode Java even nicely outputs "Print is not implemented yet" to the console, so I don't think this is our fault. I also couldn't get printing for those plugins to work on branch.

Mike, can you please look, if this makes sense code wise (yes, all that ifdef stuff is annoying but I don't see a better way). Dave could you test? Steve, do you know any other plugins that paint to the screen that I should try?

Comment 12

[Steve Wendt]

(In reply to comment #11)

> I also couldn't get printing for those plugins to work on branch.

Is support for printing plugin output something new?  I thought it was something that didn't work cross-platform.

> do you know any other plugins that paint to the screen that I should try?

Not that I can think of at the moment.

Comment 13

[Peter Weilbacher]

Plugins that are capable to be printed, like Heiko's GBM plugin, already did that on the 1.8 branch. And as far as I understand from e.g. bug 408623 at least Java should be capable to be printed.

Comment 14

[Dave Yeo]

Peter, testing on Seamonkey I don't see any differences with or without the patch. Without ipluginw, no Java and Flash crashes as soon as I move the mouse in the window. With ipluginw they both work.
Unluckily printing is currently broken on my machine and attempting to print with any app crashes the app.
I'll try Firefox once I get it to build and report if there is any differences

Comment 15

[Dave Yeo]

Ok, Firefox compiles now. Testing without ipluginw produces results the same as Seamonkey. Unluckily adding ipluginw does not make any difference. No Java and flash crashes quite easily here.

Comment 16

[Walter Meinl]

I can confirm that firefox won't load java without the ipluginw.dll, at least as long as you build with libxul. I just wanted to recompile with --enable-static --disable-shared, but now the patch try2 won't apply anymore. That's because of the checkin for bug415285 for windows. Could that be helpful for OS/2?
I made 2 experiences when the patch was still working (2 days ago).
First, I couldn't install ipluginw.xpi it gave me an error: Minefield could not install this item because "install-0w6..rdf" (provided by the item) is not well-formed or does not exist. Please contact the author about this problem. With several tries the error message was the same except the name of this install "install-xxx..rdf", where the xxx were always different (some kind of salt probably) Note the two ".." in  the name were always there. After pressing ok another window came up:
Minefield could not install the file at 
file:///E:/download/ipluginw20050915.xpi
because: Unexpected installation error
Review the Error Console log for more details.
-203
(the error console doesn't give a helpful hint)
ipluginw.xpi does not provide an install.rdf only an install.js
I don't think that this is related to the patch.
The second problem I saw could be however related to the patch. When I started a java tester page I got aware that java was not running. After that I left the browser and the system froze completely. The same (not working) site with a build where I did not apply the patch did not hang the system after leaving the browser. 

Comment 17

[Walter Meinl]

Ok, manually updating try2 and then building with --disable-libxul gave me a working Firefox, it doesn't hang the system anymore after leaving. Java works after manually installing ipluginw.dll and I don't crash (only a few sites tested) with flash7_R68. Flash runs also without ipluginw.dll in a libxul build. In a libxul build I see in the error console: Failed to load XPCOM component: D:\PROGRAMS\FIREFOX30\components\ipluginw.dll.

Comment 18

[Peter Weilbacher]

I'm not surprised that ipluginw is not prepared to search for symbols in xul.dll and hence fails. We really need to rewrite and compile ipluginw with the trunk code. But as far as testing the problem at hand goes, we can do that just as well in a build without libxul.

A note to myself, when updating this patch for the current trunk, take into account bug 418882.

Comment 19

[Peter Weilbacher]

Attachment: updated patch

Mike, can you please take a quick look if you see any problems?

Comment 20

[Mike Kaply [:mkaply]]

Comment on attachment 308125 [details] [diff] [review]
updated patch

Looks reasonable to me.

Comment 21

[Peter Weilbacher]

Comment on attachment 308125 [details] [diff] [review]
updated patch

Another OS/2 patch that touches cross-platform files.

Comment 22

[Damon Sicore (:damons)]

Comment on attachment 308125 [details] [diff] [review]
updated patch

a1.9+=damons

Comment 23

[Peter Weilbacher]

Patch checked into trunk. Yay!

I have filed bug 421988 on the ipluginw problem.