Closed Bug 59211 Opened 24 years ago Closed 23 years ago

Mouse wheel does nothing when cursor over plugin

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: ajp+mozilla, Assigned: bryner)

References

(
URL
)

Details

(Keywords: topembed)

Attachments

(1 file)

Corrected patch - prevents crashing the flash plugin
5.36 KB, patch
bryner
: review+
Details | Diff | Splinter Review 
To reproduce: Go to a site with a shockwave flash applet. http://home.excite.com
is a good example, but I believe it's only accessible to @home cable users. Put
the mouse cursor over the flash applet, and scroll the mouse wheel - nothing
happens. When you move the cursor out of the applet, the wheel works again.
Ari, yes, I cannot access the url above. Is it possible for yo uto find another 

test url for this problem? Thanks for your help.


This test URL kinda sucks but here:
http://www.atomfilms.com/spotlights/dbe/index.html
Right after the top ad banner, everything below is flash. notice the mouse wheel
works on the black area to the side of the ad up top, but not on the image or
the flash app.
URL: http://www.atomfilms.com/spotlights/d...
*** Bug 65641 has been marked as a duplicate of this bug. ***
*** Bug 68065 has been marked as a duplicate of this bug. ***
OS: Linux → All
Assignee: av → saari
Chris, is this related to what you were looking at recently?
On Windows, things are dying here:

          LONG proc = ::GetWindowLong(destWnd, GWL_WNDPROC);
          if (proc != (LONG)&nsWindow::WindowProc)  {
            // Some other app
            break;
          }

proc is null.
Blake, where is that code you just referenced?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
->bryner for consideration, clearing target.
Target Milestone: mozilla0.9.1 → ---
Chris: Windows' nsWindow.cpp
Moving to event handlin component.
Component: Plug-ins → Event Handling
bryner, giving to you. The problem is that plugins on windows create their own
native OS window, so unless there is a message that gets passed up to the parent
in this case, we have no way of knowing to scroll the page.
Assignee: saari → bryner
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla1.0
Is that what we want to do, or do we want to pass the message on to the plugin's
native window? What if the plugin wants to do something with this event?
Status: NEW → ASSIGNED
Oops, meant to keep saari cc'd.  Chris, please see the question above.
On windows, I don't think we have a choice. The native OS mouse wheel scroll
message will go to whatever native window the mouse is over. If that happens to
be a window that a plugin created, they'll get the message with us none the
wiser (since they'll have their own message handling proc that doesn't have our
scroll wheel code in it).

Now, that message, or a similar one to it, might go to the parent window (us)
and we could decide to do something with it there. Or maybe we can capture
scroll wheel events via OS event capturing and grab it before the plugin sees it?
Well, based on Blake's comment, our code is at least _seeing_ the message.  It's
possible that we got it because the plugin didn't handle it and handed it up to
its parent window.

One thing we could do here is go up the window parent list any see if any of the
ancestor windows are Mozilla windows, and handle the event there if we find one.

Bug 78450 is almost certainly a dupe of this - and as an added bonus, it has a 
patch that works perfectly for ActiveState's Komodo.  Leaving to someone else 
to mark the other as a dupe once the patch has been moved, or whatever the 
protocol is in this situation.
*** Bug 85405 has been marked as a duplicate of this bug. ***
I just uploaded another patch that prevents any plugins from crashing (always a 
good thing!)

For an example of a plugin that scrolls, go to http://www.atomfilms.com/ - 
currently the "Featured Spotlights -> The Bottle" is a page with a flash plugin 
that scrolls.

Without the patch, the mouse-wheel does nothing when over the plugin.  With the 
patch the browser frame correctly scrolls the content.  Komodo uses a plugin 
that explicitly handles the mouse-wheel, and this patch works correctly in that 
environment.

So, seeking r= for this patch :)
*** Bug 78450 has been marked as a duplicate of this bug. ***
*** Bug 87399 has been marked as a duplicate of this bug. ***
will this also fix bug 42313?
Keywords: mozilla0.9.4, review
*** Bug 95541 has been marked as a duplicate of this bug. ***
*** Bug 99888 has been marked as a duplicate of this bug. ***
Giving this bug a bit of a prod - anyone willing to offer r=?
Comment on attachment 38733 [details] [diff] [review]
Corrected patch - prevents crashing the flash plugin

r=bryner
Attachment #38733 - Flags: review+
Please post patch on 0.9.4 branch whenever it is finally sr'd.
Keywords: nsbranch+, topembed
Brian, who would be a good super reviewer? Could you make sure that you get
somebody's attention soon? Thanks. Marek
sr=hyatt

This has been checked in on the trunk... I'm inclined to let it bake there for a
couple of days before checking it into the branch.

This was originally filed as a Linux bug.  The fix is windows-only, as far as I 
can tell (if that's not the case, ignore the rest of this comment).  So either 
this bug needs to stay open or we need to file separate bugs for Mac and Linux 
before resolving this one.

yeah, I didn't realize this bug had morphed into a windows-only bug.  The fixes
for Mac and Linux will both be in platform specific code, and will likely be
done by different people, so I'd say separate bugs should be filed.  I'll do
that when I close out this bug.

I've checked in this patch to the branch.  I filed bug 102573 for the Linux
spinoff of this bug.  Haven't yet filed one for Mac because I don't have a Mac
to confirm the problem on.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verif fxd on branch. adding 'vtrunk'
Status: RESOLVED → VERIFIED
Keywords: vtrunk
I think this bug is back.  The nytimes.com web site is a good test case, because its front page contains a few flash windows.  I'm using Seamonkey 1.1 on Linux.
This bug was never fixed on Linux.  See bug 102573 and comment 33 through comment 35.
This bug is present in Firefox 2.0.0.2 for Linux please fix it very annoying
Marco, please read comment 38.  If you want it fixed on Linux, please file bugs on GTK to provide the event data needed here.
Boris I have read, but I really don't understand what I have to do, please be more specific and then I can open all the bugs :)
No idea.  I'm not an expert on either GTK or our event stuff.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: