Unreviewed chromium expectations change after r123302.
https://bugs.webkit.org/show_bug.cgi?id-91806

* platform/chromium-win/fast/forms/number/number-appearance-rtl-expected.png:
* platform/chromium-win/fast/forms/number/number-appearance-spinbutton-disabled-readonly-expected.png:
* platform/chromium-win/fast/forms/number/number-appearance-spinbutton-layer-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123349 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Part 1 of: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

Sort the ENABLE_CSS lines in the file.

* Source/cmake/WebKitFeatures.cmake:
* Source/cmakeconfig.h.cmake:

Source/JavaScriptCore: Part 1 of: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

Sort the ENABLE_CSS lines in the file. Make sure all the flags
are in FEATURE_DEFINES.

* Configurations/FeatureDefines.xcconfig:

Source/WebCore: Part 1 of: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

Sort the ENABLE_CSS lines in the file. Make sure all the flags
are in FEATURE_DEFINES.

* Configurations/FeatureDefines.xcconfig:

Source/WebKit/chromium: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

* features.gypi:

Source/WebKit/mac: Part 1 of: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

Sort the ENABLE_CSS lines in the file. Make sure all the flags
are in FEATURE_DEFINES.

* Configurations/FeatureDefines.xcconfig:

Source/WebKit2: Part 1 of: Implement sticky positioning
https://bugs.webkit.org/show_bug.cgi?id=90046

Reviewed by Ojan Vafai.

Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.

Sort the ENABLE_CSS lines in the file. Make sure all the flags
are in FEATURE_DEFINES.

* Configurations/FeatureDefines.xcconfig:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123350 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed chromium change to mark sandboxed-iframe-navigation-parent.html as slow on Windows.
https://bugs.webkit.org/show_bug.cgi?id=24182

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed chromium expectations change to mark fast/frames/frameset-frameborder-boolean-values.html as slow on snowleopard.
https://bugs.webkit.org/show_bug.cgi?id=24182

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123352 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] RenderThemeQtMobile highlight colors are not being used
https://bugs.webkit.org/show_bug.cgi?id=92004

Reviewed by Noam Rosenthal.

Source/WebCore:

The issue here is that setPaletteFromPageClientIfExists() is being used as a
virtual function, but it isn't, so when platformActiveSelectionBackgroundColor()
runs, it doesn't pick the right palette.

Besides fixing this virtual behavior, the patch changes the structure a bit,
because setPaletteFromPageClientIfExists() was being "overriden" in mobile theme
to set the palette, which isn't exactly what the function name says.

* platform/qt/RenderThemeQt.cpp:
(WebCore::RenderThemeQt::platformActiveSelectionBackgroundColor):
(WebCore::RenderThemeQt::platformInactiveSelectionBackgroundColor):
(WebCore::RenderThemeQt::platformActiveSelectionForegroundColor):
(WebCore::RenderThemeQt::platformInactiveSelectionForegroundColor):
(WebCore::RenderThemeQt::platformFocusRingColor):
(WebCore::RenderThemeQt::systemColor):
(WebCore::RenderThemeQt::getMediaControlForegroundColor):
(WebCore::RenderThemeQt::paintMediaVolumeSliderTrack):
Use the virtual colorPalette() to get the palette.

(WebCore::RenderThemeQt::colorPalette):
(WebCore): Removed the code for getting the page client from here since it is
used only by the QStyle variant.

* platform/qt/RenderThemeQt.h:
(RenderThemeQt):
* platform/qt/RenderThemeQtMobile.cpp:
(WebCore::RenderThemeQtMobile::colorPalette):
(WebCore):
* platform/qt/RenderThemeQtMobile.h:
(RenderThemeQtMobile):

Source/WebKit/qt:

* WebCoreSupport/RenderThemeQStyle.cpp:
(WebCore::RenderThemeQStyle::setPaletteFromPageClientIfExists): Moved here since
it's used only by RenderThemeQStyle. Remove unnecessary check for m_page->chrome().
(WebCore):
(WebCore::RenderThemeQStyle::colorPalette):
* WebCoreSupport/RenderThemeQStyle.h:
(RenderThemeQStyle):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123353 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unify numTouchEventHandlersChanged and needTouchEvents in the chrome client
https://bugs.webkit.org/show_bug.cgi?id=91006

Reviewed by Ryosuke Niwa.

Source/WebCore:

The rationale here is that the client doesn't need to know about the touch
event handler count. needTouchEvents was already used for that purpose.

Test: fast/events/touch/touch-handler-count.html

* dom/Document.cpp:
(WebCore::Document::Document):
(WebCore::Document::didAddTouchEventHandler): Only notify the client if needed.
(WebCore::Document::didRemoveTouchEventHandler): Ditto. Also unset the TOUCH_LISTENER
flag for the document if we reach a count of zero. The rationale being that
hasListenerType() is relied upon in other places in combination with TOUCH_LISTENER for
the same purpose.
* dom/Document.h:
(Document):
(WebCore::Document::touchEventHandlerCount):
* loader/EmptyClients.h:
* page/ChromeClient.h:
(ChromeClient):
* page/Frame.cpp: Removed notifyChromeClientTouchEventHandlerCountChanged.
(WebCore::Frame::setDocument): call needsTouchEvents directly.
* page/Frame.h: Ditto.
(Frame):
* testing/Internals.cpp:
(WebCore::Internals::hasTouchEventListener): expose Document::hasListenerType indirectly
for additional testing.
(WebCore):
* testing/Internals.h:
(Internals):
* testing/Internals.idl:

Source/WebKit/blackberry:

Removed numTouchEventHandlersChanged stub.

* WebCoreSupport/ChromeClientBlackBerry.h:

Source/WebKit/chromium:

Rename the functions to follow a more boolean logic.

* public/WebViewClient.h:
(WebKit::WebViewClient::hasTouchEventHandlers):
* src/ChromeClientImpl.cpp:
(WebKit):
(WebKit::ChromeClientImpl::needTouchEvents):
* src/ChromeClientImpl.h:
(ChromeClientImpl):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::hasTouchEventHandlers):
* src/WebViewImpl.h:
(WebViewImpl):

Source/WebKit/efl:

Removed numTouchEventHandlersChanged stub.

* WebCoreSupport/ChromeClientEfl.h:

Source/WebKit/gtk:

Remove numTouchEventHandlersChanged stub.

* WebCoreSupport/ChromeClientGtk.h:

Source/WebKit/mac:

Remove numTouchEventHandlersChanged stub.

* WebCoreSupport/WebChromeClient.h:

Source/WebKit/qt:

Remove numTouchEventHandlersChanged stub.

* WebCoreSupport/ChromeClientQt.h:

Source/WebKit/win:

Remove numTouchEventHandlersChanged stub.

* WebCoreSupport/WebChromeClient.h:

Source/WebKit/wince:

Remove numTouchEventHandlersChanged stub.

* WebCoreSupport/ChromeClientWinCE.h:

Source/WebKit/wx:

Remove numTouchEventHandlersChanged stub.

* WebKitSupport/ChromeClientWx.h:

Source/WebKit2:

Remove numTouchEventHandlersChanged stub.

* WebProcess/WebCoreSupport/WebChromeClient.h:
(WebChromeClient):

LayoutTests:

Extend the touch-handler-count test to also cover the hasListenerType logic.

* fast/events/touch/touch-handler-count-expected.txt:
* fast/events/touch/touch-handler-count.html:


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