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.

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.

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.

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.

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

Screen shot of Flash plugin working on trunk

Java plugin working on trunk

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.

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...)

(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 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).

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?

(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.

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.

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

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.

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.

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.

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.

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

Comment on attachment 308125 [details] [diff] [review] updated patch Looks reasonable to me.

Comment on attachment 308125 [details] [diff] [review] updated patch Another OS/2 patch that touches cross-platform files.

Comment on attachment 308125 [details] [diff] [review] updated patch a1.9+=damons

Patch checked into trunk. Yay! I have filed bug 421988 on the ipluginw problem.