On Mac, we don't use child windows for displaying plugins therefore when events propagate down to nsPluginViewer, we need to hand them off to the plugin ourselves. This needs to be done for for paint (update), key, and mouse events and perhaps others like it is currently being done in nsObjectFrame. Without this, I don't think full-page plugins will work on the Mac. Oh, you may need to apply this patch to get MIME types to register with layout correctly: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=19950

Applied Peter's patch and confirmed that full-page plugins do not paint on mac. Full-page plugins are instantiated via nsPluginViewer.cpp in /modules/plugin/nsglsrc

Adding back the two bugs this one blocks - don't know why my comment removed them (didn't get a collision notice).

Adding saari to cc list because I'm thinking there is probably a dependency or other tie-in to 58957 which he is working on.

Looking at CVS Blame for HandlePluginEvent in nsPluginViewer, it looks like Chris Saari was the last to touch that. I was thinking I could copy most of the code from either nsObjectFrame::HandleEvent or nsPluginInstanceOwner::ProcessEvent (#ifdef XP_MAC of course) but I think HandlePluginEvent is a little different because it's a callback and not a member function. I also don't want to litter the file with platform specific code if possible as it is pretty XP clean now. Perhaps there is a better way of doing this. Andre/Chris/Brian, any ideas?

Soo bug 58957 is a focus problem, pure and simple. Now, that may affect this bug for typing as well, but mouse events should still work inspite of that bug. Copying the code from an event handler for another platform is probably what we need to do. The ideal solution would be to make all the platforms behave consistantly with regard to windows, widgets, and event propogation but that is a much bigger task.

This should be assigned to Plug-Ins, not PICS

you may want to check this bug again given my recent round of plugin hacking

I tried to test this using the patch and testcase from bug 14496, but the results were inconclusive because the music plays, but the control window doesn't appear so I can't control it.

This bug is more than just a focus problem because we don't even send UPDATE (and PAINT) messages to the plugin. nsPluginViewer should really be instrumented with listeners, like Chris did for nsObjectFrame. I just took another look at this and it looks like the call to mWindow->Create sends in the PR_CALLBACK function HandlePluginEvent. In this non-member function, the nsGUIEvent needs to be sent to the plugin.

Right, it works on Windows because you focus the plugin's native window from that method and the events flow into the plugin owned/created window and it works from there via native OS event dispatch. On MacOS, we focus the window, events flow into it, and get dropped on the floor right there. Since this is a full page plugin, I don't think DOM listeners are quite what you want. Just dispatch the nsGUIEvent directly from HandlePluginEvent. There isn't really a page DOM to listen to for that matter. So this never worked outside of Windows. Wow.

Yeah, you are right, with no DOM, listners probably wouldn't be the right solution. But since HandlePluginEvent isn't a member of pluginInstanceOwner, I can't get at the plugin instance to pass off the event. How do I dispatch the nsGUIEvent of the non-member HandlePluginEvent to the plugin instance which is a memeber of pluginInstanceOwner? Am I missing something here?

No, you're not missing anything, we just don't have the architecture set up to support non-windows platforms right now. :-( I worked out a hack for this last night, but I'm not sure how to test it (don't think I have a full page plugin example). Basically all I did was attempt to dispatch the event into the view system like normal from HandlePluginEvent. ... but I have no idea if we even have a view in this case. I would assume so, but I don't know. Also, I don't know where the event would go from there. Ideally we could get it to the plugin containing structure, and add event handling code there to dispatch it into the plugin instance like we do in nsObjectFrame

Chris, I'm not familiar with the code on how events go through the view system, but the patch I've attached basically mimics the functions in nsObjectFrame for disptaching events the plugin instance. I haven't been able to test it yet and the patch isn't complete because of my previous comments but perhaps it may help you on your end. For testing, I've found the Acrobat PDF viewer plugin a good to use for events but rather complex. It has scrollbars, and toolbars, and a bunch of other things. The Quicktime plugin and testcase in bug 14496 is probably the best to use as it is simplier and at least you hear music so you know something is working. Be sure to apply the patch in that bug to correctly define PLUGIN_DLL. I guess that was left off to force full-page plugins to work as helper apps on the Mac.

Your patch looks pretty much exactly like my first attempt, but as you discovered, that won't work. We need a more involved solution, unfortunately. I'll try and test out my other ideas soon.

Well I tried my patch with bug 14496 and everything worked okay, so maybe I fixed it by the seat of my pants. Heard the music, could click to stop it, start it again, etc. Patch coming up...

Hrm, it shouldn't have worked... are you sure bug 14496 doesn't work okay as is? Everytime I try the Acrobat reader, mozilla just wants to save the PDF file to disk.

Oh Chris, you are close if Quicktime is working. You aren't applying the PLUGIN_DLL patch in bug 14496. Try this: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=19950

Nope, I did apply that patch before testing... what am I missing?

Okay, I think I was testing the wrong thing. This still does not work right: http://www.prometheus-music.com/gecko/KQ4GS1.mid

Can you attach your patch here?

Your patch is as good as mine right now. I can't get the events to the plugin instance. I tried finding a view for the widget to dispatch the event to and that didn't work either, no view. Hrm. I need to understand the object hierarchy for full page plugins better. There has to be some way we can find an event handler from that callback and get back to the plugin instance owner to dispatch the event to the plugin.

How about the nsWindow? Or perhaps we can create a Widget wrapper or something similar to what's in nsObjectFrame?

Kevin tipped me off to Get/SetClientData() which can store a weak reference gack to nsPluginViewer and pass off the events during callback.

With this patch, full page plugins now sort of work. Events are getting through, however, it's not perfect. Try the Acrobat testcase in bug 35682. One problem, is painting with the testcase in bug 14496. Update event only sent to plugin when window is resized. Could need a timer? Also, client area not in plugin doesn't repaint. Anyone know how I tell mWindow (nsIWidget)'s parent to paint?

>Also, client area not in plugin doesn't repaint. I don't think this works on windows with full page plugins either.

Setting milestone and adding testcase. Can we attach as many full page plugin testcases to this bug as possible. It would sure help in debugging. Thanks.

testcases : http://www.macromedia.com/software/flash/spotlight_flash.swf http://slip/shrir/ACTIVEX.HTML http://www.prometheus-music.com/gecko/KQ4GS1.mid http://slip/shrir/pdffullpage.html http://slip/shrir/square.swf http://slip/shrir/embedpdf.html http://www.prometheus-music.com/gecko/plugtest1.html

Sean, Based on Shrir's testcases, Windows seems to work completely. Can you show me a case where it doesn't paint on Windows? Time to try Mac again. Thanks.

With the flash animation, it looks like it gets "stuck". But moves if I slightly resize the window. Andrei, is this what the "Timer" is for on Mac?

To my understanding -- yes. Patric Beard can probably say more.

Yes. The purpose of the timer is to send NULL events to the plugin see nsPluginInstanceOwner::Notify() in nsObjectFrame.

peter wrote: >Based on Shrir's testcases, Windows seems to work completely. Can you show me a >case where it doesn't paint on Windows? Nope - I recollected incorrectly.

One step closer to finishing this. This above patch sends NULL events so animations and progress indicators seem to work. However, there is still MUCH left to do with Paint events (constant event code 130). The content area or chrome does not update. I'm going to try to trap this paint/update event, get the mWindow's parent, tell it to paint/update, then pass off the paint/update to the plugin. I don't know the widget system that well, but I think if I tell the widget's parent to paint, this will cause everything to repaint, including the chrome. Kevin, ideas? I'll show you on my Mac if you want to see this weird behavior.

Good progress being made. I found a way to send NS_PAINT events to the plugin therefore making the plugin visible, controlable, and almost fully workable. So now I just need to set the port correctly first because it seems to think that is should paint at 0,0 which is over the chrome. Good thing that code is mostly written in nsObjectFrame. Other action item left is the crash when leaving a page with a full page plugin. I think a stray event is getting through so a some null pointer checks should clear that up. Note, you won't see your PDF document quite yet because of the painting issue. I've been using Quicktime MIDI file as a simplified testcase. Setting ETA to 3/19

The 4th edition of the patch now seems to be closer to the final draft. Even though it's a rough draft (needs some clean up), Quicktime in full-page mode work great so bug 14496 can be almost resolved. Full-page Flash also works! However, Acrobat PDF still doesn't work. I'm thinking it's the same problem on the Mac as on Windows. I will investigate further as PDF is the REAL goal in getting full-page plugins to work.

The 5th patch is pretty good. Almost there. Two items I need help on (please advise): 1. If PDF gets focus, then chrome gets focus, then PDF gets focus, chrome never gets focus again?????? 2. "Access Violation" on opening Acrobat Embeded Prefs.

Changing ETA one week to fix crashing case.

*** This bug has been marked as a duplicate of 35682 ***

Lots of verifications. If I had to test stuff, it was on Win2K, build id 2001052404.