Unreviewed gardening. The previous rebaseline didn't quite get it right for Mac.

* platform/chromium-mac-lion/platform/chromium/fast/forms/suggestion-picker/date-suggestion-picker-appearance-with-scroll-bar-expected.png:
* platform/chromium-mac-lion/platform/chromium/fast/forms/suggestion-picker/month-suggestion-picker-appearance-with-scroll-bar-expected.png:
* platform/chromium-mac-lion/platform/chromium/fast/forms/suggestion-picker/week-suggestion-picker-appearance-with-scroll-bar-expected.png:
* platform/chromium-mac/platform/chromium/fast/forms/suggestion-picker/date-suggestion-picker-appearance-with-scroll-bar-expected.png:
* platform/chromium-mac/platform/chromium/fast/forms/suggestion-picker/month-suggestion-picker-appearance-with-scroll-bar-expected.png:
* platform/chromium-mac/platform/chromium/fast/forms/suggestion-picker/week-suggestion-picker-appearance-with-scroll-bar-expected.png:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138180 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Correct missing touch event handler de-registration for nested Documents and DOMWindows
https://bugs.webkit.org/show_bug.cgi?id=105384

Reviewed by James Robinson.

Source/WebCore: 

Correcting case by which a nested DOMWindow wouldn't clean up its event handler references
on its Document when removeAllEventListeners was called. Also, correctly propagating this
from a nested Document to its owner Document.

Updating fast/events/touch/touch-handler-count.html to catch this bug.

* dom/Document.cpp:
(WebCore::Document::didRemoveEventTargetNode):
* page/DOMWindow.cpp:
(WebCore::DOMWindow::removeAllEventListeners):

LayoutTests: 

* fast/events/touch/touch-handler-count-expected.txt:
* fast/events/touch/touch-handler-count.html: Adding case of nested DOMWindows with event handlers.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Popup menu on Windows should fade in instead of sliding in.
https://bugs.webkit.org/show_bug.cgi?id=105358
<rdar://problem/7611211>

Reviewed by Timothy Horton.

Changing popup menu display animation to match what most other Windows applications do.

* platform/win/PopupMenuWin.cpp:
(WebCore::PopupMenuWin::show):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make RenderLayerCompositor::requiresCompositingForScrollableFrame scrollbars agnostic
https://bugs.webkit.org/show_bug.cgi?id=97903

Reviewed by Simon Fraser.
Patch by Antonio Gomes <a1.gomes@sisa.samsung.com>

Some ports (including Qt-wk1 and BlackBerry) allow disabling
scrollbars at FrameView creation level. Regardless the scrollbars
presence though, their frame's content can still be scrolled as needed.
The said, checking for the scrollbars presence in order to determine
the scrollability of an inner frame is flaky, as done in RenderLayerCompositor::requiresCompositingForScrollableFrame.

Instead, the patch factors out part of the logic in
FrameView::updateScrollableAreaSet into a new ::isScrollable method.
The later can be used to check the scrollability of a given FrameView.

No new tests added, since there is no behavior change: ports like Chromium and others
who currently check for the scrollbars presence in order to determine
an inner frame scrollability should not be affected.

* page/FrameView.cpp:
(WebCore::FrameView::isScrollable):
(WebCore):
(WebCore::FrameView::updateScrollableAreaSet):
* page/FrameView.h:
(FrameView):
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresCompositingForScrollableFrame):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138183 268f45cc-cd09-0410-ab3c-d52691b4dbfc