Bug 53419 – WebKit's WebHTML2View does not "eat" the scroll wheel event after processing it

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit API

This issue was found on Mac+Safari5.0 

This is a bug in WebKit's WebHTML2View -- it does not "eat" the scroll wheel event after processing it. Then the scroll wheel event is passed to the lower level, and the lower level window is scrolled too. 

Here is the detail description for this bug:(It's an analysis from an Acrobat developer)
===============================================
When the "pop-up window" (which isn't a window, it's actually just a view that's partially over the AdobePDFView) receives scroll wheel event, the event is passed thru the "pop up window" view and passed to Acrobat using this callstack:

#1	0x1cb415de in -[CocoaAVGenericControl scrollWheel:] at AVControlMac.cpp:921
#2	0x91f2dac1 in forwardMethod
#3	0x921058b5 in -[NSView scrollWheel:]
#4	0x93ab991b in -[WebDynamicScrollBarsView(WebInternal) scrollWheel:]
#5	0x91f2dac1 in forwardMethod
#6	0x921058b5 in -[NSView scrollWheel:]
#7	0x93ab966e in -[WebClipView scrollWheel:]
#8	0x91f2dac1 in forwardMethod
#9	0x921058b5 in -[NSView scrollWheel:]
#10	0x93ab93ad in -[WebHTMLView scrollWheel:]
#11	0x968c12d9 in WebCore::EventHandler::passWheelEventToWidget
#12	0x9628265c in WebCore::EventHandler::handleWheelEvent
#13	0x96282296 in WebCore::EventHandler::wheelEvent
#14	0x93ab9381 in -[WebHTMLView scrollWheel:]
#15	0x92017d38 in -[NSWindow sendEvent:]
#16	0x00040a8d in ??
#17	0x00040a1a in ??
#18	0x91f30817 in -[NSApplication sendEvent:]
#19	0x00037c95 in ??
#20	0x91ec42a7 in -[NSApplication run]
#21	0x91ebc2d9 in NSApplicationMain
#22	0x0000ae99 in ??

The "pop-up window" view should have eaten that event and not passed it on...  

The portion of the hierarchy we're interested in is:

WebHTMLView
	WebFrameView	(the HTML content)
	AdobePDFView	(the PDF content)
	WebFrameView	(the pop-up window)

Here's the problem...  When we get any event, the view that receives the hit test for the event is actually the parent WebHTMLView (it later on forwards the event).   Unfortunately we don't have any z-order information, so we don't know at runtime which of those three subviews are actually the target of the event -- so there's no way for us to tell which of those three views is right under the cursor...

The only client who has that z-order information is the parent WebHTMLView -- and that's part of WebKit.  So the correct fix would be to make a change to WebKit so that it can handle this sort of event.

[Alexey Proskuryakov]

Could you please provide steps to reproduce the problem? What site should one open to see this, and what actions to perform?

[Ahmad Saleem]

I think at this point, this bug is not actionable, marking this as 'RESOLVED WONTFIX'.