<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.
I have a patch for this but I haven’t finished the regression test yet.
Created attachment 50563 [details] Dispatch a fake mouse move event shrotly after scrolling
Attachment 50563 [details] did not build on chromium: Build output: http://webkit-commit-queue.appspot.com/results/642040
Created attachment 50574 [details] Dispatch a fake mouse move event shrotly after scrolling
Attachment 50574 [details] did not build on chromium: Build output: http://webkit-commit-queue.appspot.com/results/643033
Created attachment 50576 [details] Dispatch a fake mouse move event shrotly after scrolling
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
Fixed in <http://trac.webkit.org/projects/webkit/changeset/55909>.
This change broke the Chromium Win Release build: http://build.webkit.org/builders/Chromium%20Win%20Release/builds/3286/steps/compile-webkit/logs/stdio
Build fix in <http://trac.webkit.org/projects/webkit/changeset/55911>.