Bug 35949

Summary: Hover states not updated when overflow section scrolls under stationary mouse pointer
Product: WebKit Reporter: mitz
Component: Layout and RenderingAssignee: mitz
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov, gdk, webkit.review.bot
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Dispatch a fake mouse move event shrotly after scrolling
none
Dispatch a fake mouse move event shrotly after scrolling
none
Dispatch a fake mouse move event shrotly after scrolling darin: review+

mitz
Reported 2010-03-09 16:29:01 PST
<rdar://problem/7694674> When an overflow: scroll; section is scrolled and different elements move under the mosue cursor, hover states don’t update to reflect the change, tool tips don’t update, and mouseover/mouseout events aren’t fired.
Attachments
Dispatch a fake mouse move event shrotly after scrolling (15.52 KB, patch)
2010-03-11 17:32 PST, mitz
no flags
Dispatch a fake mouse move event shrotly after scrolling (15.71 KB, patch)
2010-03-11 19:32 PST, mitz
no flags
Dispatch a fake mouse move event shrotly after scrolling (19.76 KB, patch)
2010-03-11 22:30 PST, mitz
darin: review+
mitz
Comment 1 2010-03-09 23:44:47 PST
I have a patch for this but I haven’t finished the regression test yet.
mitz
Comment 2 2010-03-11 17:32:20 PST
Created attachment 50563 [details] Dispatch a fake mouse move event shrotly after scrolling
WebKit Review Bot
Comment 3 2010-03-11 17:58:36 PST
mitz
Comment 4 2010-03-11 19:32:32 PST
Created attachment 50574 [details] Dispatch a fake mouse move event shrotly after scrolling
WebKit Review Bot
Comment 5 2010-03-11 20:29:40 PST
mitz
Comment 6 2010-03-11 22:30:33 PST
Created attachment 50576 [details] Dispatch a fake mouse move event shrotly after scrolling
Darin Adler
Comment 7 2010-03-12 07:42:23 PST
Comment on attachment 50576 [details] Dispatch a fake mouse move event shrotly after scrolling > +void EventHandler::cancelFakeMouseMoveEvent() > +{ > + if (!m_fakeMouseMoveEventTimer.isActive()) > + return; > + > + m_fakeMouseMoveEventTimer.stop(); > +} I don't think you need to check isActive before calling stop. It's safe to call it even if the timer is not active. > +void EventHandler::fakeMouseMoveEventTimerFired(Timer<EventHandler>* timer) > +{ > + ASSERT_ARG(timer, timer == &m_fakeMouseMoveEventTimer); You need to use ASSERT_UNUSED here because "timer" is otherwise unused in this function. I think this is why the Mac EWS build indicates a failure. I'm a little sad that the test requires a timeout and can't run instantaneously. Could it instead be based on the timing of the first mouse move event? r=me, but please fix the Mac build issue
mitz
Comment 8 2010-03-12 09:07:28 PST
Garret Kelly
Comment 9 2010-03-12 09:58:51 PST
mitz
Comment 10 2010-03-12 10:09:29 PST
Note You need to log in before you can comment on or make changes to this bug.