[Chromium] Unreviewed gardening.

Win build fix after http://trac.webkit.org/changeset/141471.

* DumpRenderTree/chromium/TestRunner/src/MockSpellCheck.cpp:
(MockSpellCheck::spellCheckWord):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141478 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Editor::m_compositionNode not updated on HTMLInputElement::setValue()
https://bugs.webkit.org/show_bug.cgi?id=107737

Patch by Aurimas Liutikas <aurimas@chromium.org> on 2013-01-31
Reviewed by Ryosuke Niwa.

Source/WebCore:

Chromium has a bug where the IME composition did not get cancelled on JavaScript changes
to the focused editing field. Most of other WebKit ports were already doing this check
in their EditorClient::respondToChangedSelection. I took that logic and moved it to the
Editor so every port and use the same code.

An existing test editing/input/setting-input-value-cancel-ime-composition.html covers this change.
This test used to have an expectation to fail on Chromium and after this patch it will start passing.

* editing/Editor.cpp:
(WebCore::Editor::cancelCompositionIfSelectionIsInvalid):
    Adding a call that can be used by any the port to cancel the composition if it's no longer valid.
(WebCore):
* editing/Editor.h:
(Editor):

Source/WebKit/chromium:

* public/WebViewClient.h:
(WebKit::WebViewClient::didCancelCompositionOnSelectionChange):
    Adding a callback to let the WebViewClient know that the composition has been cancelled.
* src/EditorClientImpl.cpp:
(WebKit::EditorClientImpl::respondToChangedSelection):
    Adding a call composition if it is no longer valid.

Source/WebKit/efl:

* WebCoreSupport/EditorClientEfl.cpp:
(WebCore::EditorClientEfl::respondToChangedSelection):
    Adding a call to the newly refactored method.

Source/WebKit/gtk:

* WebCoreSupport/EditorClientGtk.cpp:
(WebKit::EditorClient::respondToChangedSelection):
    Adding a call to the newly refactored Editor method.

Source/WebKit/mac:

* WebView/WebHTMLView.mm:
(-[WebHTMLView _updateSelectionForInputManager]):

Source/WebKit/win:

* WebView.cpp:
(WebView::updateSelectionForIME):
    Adding a call to the newly refactored method.

LayoutTests:

* platform/chromium/TestExpectations: Removed fail expectation for the editing/input/setting-input-value-cancel-ime-composition.html since this patch fixes the bug https://bugs.webkit.org/show_bug.cgi?id=55560

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141479 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Parse custom filter function with the at-rule reference syntax
https://bugs.webkit.org/show_bug.cgi?id=108351

Reviewed by Dean Jackson.

Source/WebCore:

This patch implements the parsing for the new custom filter function "at-rule reference"
syntax. It does not implement the style resolution yet.

The custom function syntax has changed in the spec. Instead of including all of the custom
filter information inline, the custom function can now reference an @filter rule by name.
The custom function can still accept a list of parameters.

The syntax is defined as the following, where IDENT is the name of the @filter rule:
filter: custom(IDENT [, <param>]*)

In practice, it can look like this:
filter: custom(page-curl, direction 90, amount 0.5);

Spec: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#customident-ltparamgt

Tests: css3/filters/custom-with-at-rule-syntax/parsing-custom-function-invalid.html
       css3/filters/custom-with-at-rule-syntax/parsing-custom-function-valid.html

* css/CSSParser.cpp:
(WebCore::CSSParser::parseCustomFilterParameters):
    Factor out a new function that just parses custom filter parameters. This is used by the
    previous inline syntax and the new at-rule reference syntax.
(WebCore):
(WebCore::CSSParser::parseCustomFilterFunctionWithAtRuleReferenceSyntax):
    This method parses the new at-rule reference syntax. When we remove the inline syntax,
    we can rename this method to "parseCustomFilterFunction" and call it directly.
(WebCore::CSSParser::parseCustomFilterFunctionWithInlineSyntax):
    Move the previous inline syntax parsing code into a new function.
(WebCore::CSSParser::parseCustomFilterFunction):
    This method looks ahead in the CSS parser values and decides whether to parse the custom
    function with the previous inline syntax or with the new at-rule reference syntax.
(WebCore::CSSParser::parseFilter):
    I renamed the "parseCustomFilter" method to "parseCustomFilterFunction" to be more
    explicit. Here, we update the name in the call site.
* css/CSSParser.h:
* css/StyleResolver.cpp:
(WebCore::StyleResolver::createCustomFilterOperationWithAtRuleReferenceSyntax):
    This is a stub method. In the future, style resolution for the at-rule reference
    syntax will happen here. When we remove the inline syntax, we can rename this method
(WebCore::StyleResolver::createCustomFilterOperationWithInlineSyntax):
    This method contains the previous inline syntax style resolution code.
(WebCore):
(WebCore::StyleResolver::createCustomFilterOperation):
    This method decides which syntax we should use to resolve the style.
* css/StyleResolver.h:
(StyleResolver):

LayoutTests:

Add positive and negative parsing tests for the new custom function syntax.

Add a new folder "css3/filters/custom-with-at-rule-syntax". This will contain all the tests
using the new custom filters at-rule syntax. We will gradually copy tests in
"css3/filters/custom" over to "css3/filters/custom-with-at-rule-syntax" and modify them to
use the new at-rule syntax. When all of the tests have been replicated using the new syntax,
we will remove the previous syntax and the tests in "css3/filters/custom".

* css3/filters/custom-with-at-rule-syntax/parsing-custom-function-invalid-expected.txt: Added.
* css3/filters/custom-with-at-rule-syntax/parsing-custom-function-invalid.html: Added.
* css3/filters/custom-with-at-rule-syntax/parsing-custom-function-valid-expected.txt: Added.
* css3/filters/custom-with-at-rule-syntax/parsing-custom-function-valid.html: Added.
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-custom-function-invalid.js: Added.
(testInvalidFilterRule):
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-custom-function-valid.js: Added.
(testFilterProperty):
* css3/filters/script-tests/custom-filter-parsing-common.js:
(heading):
    New function to print a heading to make groups of related parsing tests easier to see.
(shouldHaveConstructor):
    New function to check the JS type of an object on JSC as well as V8. This is intended to
    eventually replace shouldBeType, which works differently on V8 vs. JSC and requires us
    to create Chromium-specific expectations for the custom filters parsing tests.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Bing Images viewport causes layout "fun"
https://bugs.webkit.org/show_bug.cgi?id=108393

Patch by Jacky Jiang  <zhajiang@rim.com>.
Reviewed by Yong Li.
Internally reviewed by Arvid Nilsson and partially reviewed by Konrad Piascik.

Source/WebCore:

PR: 277855
On bing.com image search page, JS generated styles for the divs which
contained images based on the window.screen and window.innerWidth.
Unfortunately the styles for the divs weren't good enough on our device
which resulted in three images being overlapped in the same viewport.
On our port, we calculate the screen rect base on the physical screen
pixels. However, iOS and lastest Android Chrome port already changed it
to density-independent (logical) pixels. And also to my knowledge that
some websites would generate bad styles for us as well through
@media device-width/device-height.
To be consistent and fix such kinds of issues, we should use
density-independent pixels instead of physical screen pixels. Mainly
ported from Chrome port change r139356. The patch will affect
screen.width/height, window.outerWidth/outerHeight and
@media device-width/device-height.

* platform/blackberry/PlatformScreenBlackBerry.cpp:
(WebCore):
(WebCore::toUserSpace):
(WebCore::screenAvailableRect):
(WebCore::screenRect):

Source/WebKit/blackberry:

PR: 277855
Set applyPageScaleFactorInCompositor settting to false by default.
Scale down chrome window rect to density-independent pixels.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::didChangeSettings):
* Api/WebSettings.cpp:
(WebKit):
(BlackBerry::WebKit::WebSettings::standardSettings):
(BlackBerry::WebKit::WebSettings::applyDeviceScaleFactorInCompositor):
(BlackBerry::WebKit::WebSettings::setApplyPageScaleFactorInCompositor):
* Api/WebSettings.h:
* WebCoreSupport/ChromeClientBlackBerry.cpp:
(WebCore::ChromeClientBlackBerry::windowRect):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141481 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use a Vector for IPC attachments
https://bugs.webkit.org/show_bug.cgi?id=108517

Reviewed by Sam Weinig.

* Platform/CoreIPC/ArgumentDecoder.cpp:
(CoreIPC::ArgumentDecoder::create):
(CoreIPC::ArgumentDecoder::ArgumentDecoder):
(CoreIPC::ArgumentDecoder::removeAttachment):
* Platform/CoreIPC/ArgumentDecoder.h:
(ArgumentDecoder):
* Platform/CoreIPC/Connection.h:
* Platform/CoreIPC/MessageDecoder.cpp:
(CoreIPC::MessageDecoder::create):
(CoreIPC::MessageDecoder::MessageDecoder):
* Platform/CoreIPC/MessageDecoder.h:
(MessageDecoder):
* Platform/CoreIPC/mac/ConnectionMac.cpp:
(CoreIPC::createMessageDecoder):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141482 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Rework page scale factor limits initialization
https://bugs.webkit.org/show_bug.cgi?id=108446

Reviewed by James Robinson.

When loading a page with viewportEnabled, both the limits
specified by the viewport tag and the content width need to be
considered before we initialize the minimum page scale (and
pageScaleFactor itself usually to the same value). The timing has
proven tricky to get correct.

This patch simplifies the flow by computing the
limits only at the end of layouts and at no other time. In combination
with https://bugs.webkit.org/show_bug.cgi?id=107922 which sets
needsLayout() appropriately, this results in a more robust and easy
to understand sequence.

Fixes FixedLayoutInitializeAtMinimumPageScale test.

* src/ChromeClientImpl.cpp:
(WebKit::ChromeClientImpl::dispatchViewportPropertiesDidChange):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::WebViewImpl):
(WebKit::WebViewImpl::resize):
(WebKit::WebViewImpl::setPageScaleFactorLimits):
(WebKit::WebViewImpl::computePageScaleFactorLimits):
(WebKit::WebViewImpl::layoutUpdated):
(WebKit::WebViewImpl::didChangeContentsSize):
* src/WebViewImpl.h:
(WebKit::WebViewImpl::setInitialPageScaleFactor):
(WebViewImpl):
* tests/WebFrameTest.cpp:

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