1) load http://gunbuster/yulian/applets/Entertainment/Games/Asteroids/Asteroids.html 2) click on the asteriods applet 3) attempt to use the scrollbar, see that it doesn't respond at all.

Rough first pass patch coming...

Adding branch accept to status whiteboard. Chris, please check into the branch ASAP. Thx. .Angela...

av, bnesse, peterl, could one or more of you review this please?

The patch is good, though at some point I'd like to see the #ifdef code and commented out stuff cleaned up some in nsObjectFrame::HandleEvent(). r=bnesse

Do we now have the same code path for all platforms in nsObjectFrame::HandleEvent() dealing with focus messages only?

It's not quite identical, but it's much closer. There is some #ifdef XP_WIN code which checks the window type before processing the event, and in the non #ifdefed case there is a case for NS_DESTROY which kills a timer. It appears that this timer is only created on the Mac (see nsPluginInstanceOwner::CreateWidget) but there is support code for all platforms.

[r/sr]=waterson, whichever helps

This patch is great for scrollbars except there is still the problem of keybord shortcuts not working. I could file it as a seperate bug if you like. For example, try closing the browser window <APPLE+W> while viewing a Quicktime movie: http://www.apple.com/trailers/newline/thirteen_days.html

Chris and I talked about this a while back. While the plugin has focus it gets keys. It is possible that the plugin might use command keys (though I would think it unlikely... even more so if the plugin it XP.) As I see it there are two possibilities. 1) We NEVER send command keys to the plugin. 2) We count on the plugin to correctly respond that they DIDN'T handle the key event. I was going to try modifing my plugin sample to handle some key events and see if option 2 is even a possibility, but I haven't had a chance. What happens on the PC if a plugin uses the ctrl or alt keys? Do we pass them to the plugin first and the application second?

Oh this is not good. On Windows you get a crash. I have the patch in my tree. Load the Quicktime page. Notice ALT+F works fine at first. Click on the movie to give the plugin focus Now click ALT+F again. Crash in ns4xPluginInstance::HandleEvent. Looks like the event pointer is bogus.

I am crashing on the windows branch (20010124) even while trying to load this movie that Peter mentioned. Also crashing on other movies on quicktime.com

Doh, okay, I'll fix it before checking in.

I am seeing this crashing of quicktime on last night's windows_branch build (20010124). Was this already checked in on windows ? I am a bit confused..since this bug is still 'open'.

old patch checked in on branch, not trunk, thus open. The crash is because the native event isn't filled in by my new code. Wonder why this didn't crash with the other tests...

trunk patch C:\gecko\mozilla\layout\events\src>cvs diff nsEventStateManager.cp Index: nsEventStateManager.cpp ================================================================== RCS file: /cvsroot/mozilla/layout/events/src/nsEventStateManager.c retrieving revision 1.232 diff -r1.232 nsEventStateManager.cpp 1560a1561 > event.nativeMsg = ((nsMouseEvent*)aEvent)->nativeMsg 1605c1606,1607 < --- > event.nativeMsg = ((nsMouseEvent*)aEvent)->nativeMsg; > 1658a1661 > event.nativeMsg = ((nsMouseEvent*)aEvent)->nativeMsg;

reviewers and super-reviewer: please confirm that this fix does not affect any other code besides plug-in code. For testing, we will focus on plug-ins only. Thank you.

r=pinkerton. this won't affect any non-plugin code (and could only make it better if it did).

sr=waterson

Checked into branch, marking fixed.

Theo original bug about scrollbars not responding is verified on mac and windows branch builds(0126). Also, the repurcussion bug about quicktime movies crashing the browser on windows is fixed too. Verified on the branch (0126), no side-effects seen with other plugins testing. Marking VERIFIED.

thanks for the quick turnaround. Shrir - when you get a chance next week, may want to verify on trunk as well. I couldn't tell by comments after 1-25 if a fix was checked to trunk or not.

this is not fixed on the trunk. Just checked on today's trunk on mac (0126). Chris, pls chek this in the trunk as well. Thanks!!

reopen for trunk tracking so we get this back on the radar. Branch is all taken care of.

okay, checked into trunk

*** Bug 65500 has been marked as a duplicate of this bug. ***

verified on mac trunk. Scrollbar respond now when clicked with mouse after focussing inside plugin region (20010130). removing 'verifed on branch' and "needs trunk check-in' since this is already checked in.