[chromium/mac] Map NSEventPhaseMayBegin appropriately on 10.8
https://bugs.webkit.org/show_bug.cgi?id=93535

Patch by Alexei Svitkine <asvitkine@chromium.org> on 2012-08-08
Reviewed by Dimitri Glazkov.

This enables putting two fingers on the track pad to show overlay scroll bars on 10.8+.

* src/mac/WebInputEventFactory.mm:
(WebKit::phaseForNSEventPhase):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125125 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rewire the same-origin checks for the JavaScriptCore bindings through BindingSecurity
https://bugs.webkit.org/show_bug.cgi?id=93382

Reviewed by Eric Seidel.

This patch rewires the same-origin policy checks in the JavaScriptCore
bindings to use the implementation in BindingSecurity.cpp, which is now
shared by JavaScriptCore and V8. There are still a few places were we
use the JSDOMWindowCustom-based code path, but I plan to change those
in a follow up patch in the interest of keeping this patch as small as
possible.

This patch as two main benefits:

1) We no longer need to maintain duplicate code in the JSC and the V8
   bindings for as delicate an area as the same-origin check.
   Previously, the two implementations accomplished the same task using
   a slightly different mechansim. After this patch, they use the same
   mechanism, which means we only need to convince ourselves that one
   implementation is correct.

2) This patch will make it easier to remove DOMWindow::m_securityOrigin
   because there will be only one piece of code that needs to change.
   Prior to this patch, we would have had to change both
   implementations of the same-origin policy not to rely upon
   DOMWindow::m_securityOrigin.

* bindings/js/BindingState.cpp:
(WebCore::immediatelyReportUnsafeAccessTo):
(WebCore):
* bindings/js/BindingState.h:
(WebCore):
* bindings/js/JSDOMBinding.cpp:
(WebCore::shouldAllowAccessToNode):
(WebCore::shouldAllowAccessToFrame):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125126 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Invalid shaders should act as pass-through filters
https://bugs.webkit.org/show_bug.cgi?id=93405

Reviewed by Dean Jackson.

Source/WebCore:

If the shader fails to apply then clearShaderResult will just copy the result of the previous filter
to the output of the current filter.

Test: css3/filters/custom/invalid-custom-filter-shader.html

* platform/graphics/filters/FECustomFilter.cpp:
(WebCore::FECustomFilter::platformApplySoftware):
(WebCore):
(WebCore::FECustomFilter::clearShaderResult):
(WebCore::FECustomFilter::applyShader):
* platform/graphics/filters/FECustomFilter.h:
(FECustomFilter):
* rendering/style/StyleCustomFilterProgram.h: The test was exposing the fact that if the shaders were referencing the same
file then StyleCustomFilterProgram will never complete the load. Having the same file for both the vertex and the fragment shader
cannot really work, because the shaders would not compile anyway, thus triggering an invalid shader.
I'm fixing it part of this change because the current test actually exposes that on Safari Mac builds. See the note in the LayoutTest/ChangeLog.
(WebCore::StyleCustomFilterProgram::notifyFinished):

LayoutTests:

Note that invalid-custom-filter-shader-expected.html is actually using another builtin filter,
just to make sure we trigger the whole FilterEffectRenderer on the images, otherwise the result will be
slightly different because of the conversion errors. Having another filter like grayscale(0) will trigger
the same precission errors on the result of the expected html.

* css3/filters/custom/invalid-custom-filter-shader-expected.html: Added.
* css3/filters/custom/invalid-custom-filter-shader.html: Added.
* css3/filters/resources/invalid-shader.vs: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125128 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Move scrollbar pointer into WebScrollbarThemePainter
https://bugs.webkit.org/show_bug.cgi?id=93541

Reviewed by James Robinson.

Source/Platform:

Update WebScrollbarThemePainter to encapsulate a pointer to the
scrollbar as well. Lion scrollbars and RenderScrollbars are both
incompatible with wrapping a scrollbar in a WebScrollbar.

ScrollbarTheme(Chromium)Mac attaches extra data to a scrollbar based
on the pointer value (via a static map keyed on the pointer) so
passing an object that returns all the same values for the
ScrollbarThemeClient interface but has a different pointer will fail
to paint.

RenderScrollbar does static casts on the ScrollbarThemeClient pointer
that it is passed, assuming that it is the same. Therefore, it also
cannot use a WebScrollbar.

To fix this, push the real scrollbar pointer into the painter.

* chromium/public/WebScrollbarThemePainter.h:
(WebCore):
(WebKit::WebScrollbarThemePainter::WebScrollbarThemePainter):
(WebScrollbarThemePainter):

Source/WebCore:

Update clients of WebScrollbarThemePainter.

* page/scrolling/chromium/ScrollingCoordinatorChromium.cpp:
(WebCore::createScrollbarLayer):
* platform/graphics/chromium/ScrollbarLayerChromium.cpp:

Source/WebKit/chromium:

Fix WebScrollbarThemePainter implementation to make direct calls on
the scrollbar rather than through the WebScrollbarThemeClientImpl
adapter.

* src/WebScrollbarThemePainter.cpp:
(WebKit::WebScrollbarThemePainter::assign):
(WebKit::WebScrollbarThemePainter::paintScrollbarBackground):
(WebKit::WebScrollbarThemePainter::paintTrackBackground):
(WebKit::WebScrollbarThemePainter::paintBackTrackPart):
(WebKit::WebScrollbarThemePainter::paintForwardTrackPart):
(WebKit::WebScrollbarThemePainter::paintBackButtonStart):
(WebKit::WebScrollbarThemePainter::paintBackButtonEnd):
(WebKit::WebScrollbarThemePainter::paintForwardButtonStart):
(WebKit::WebScrollbarThemePainter::paintForwardButtonEnd):
(WebKit::WebScrollbarThemePainter::paintTickmarks):
(WebKit::WebScrollbarThemePainter::paintThumb):
(WebKit::WebScrollbarThemePainter::WebScrollbarThemePainter):
* tests/ScrollbarLayerChromiumTest.cpp:
(WebCore::TEST):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125130 268f45cc-cd09-0410-ab3c-d52691b4dbfc
nrwt: rename finder.py to layout_test_finder.py
https://bugs.webkit.org/show_bug.cgi?id=93557

Reviewed by Ryosuke Niwa.

One last cleanup per old review feedback from rniwa.

* Scripts/webkitpy/layout_tests/controllers/layout_test_finder.py: Renamed from Tools/Scripts/webkitpy/layout_tests/controllers/finder.py.
(LayoutTestFinder):
(LayoutTestFinder.__init__):
(LayoutTestFinder.find_tests):
(LayoutTestFinder._strip_test_dir_prefixes):
(LayoutTestFinder._strip_test_dir_prefix):
(LayoutTestFinder._read_test_names_from_file):
(LayoutTestFinder._strip_comments):
(LayoutTestFinder.skip_tests):
(LayoutTestFinder.split_into_chunks):
* Scripts/webkitpy/layout_tests/controllers/manager.py:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125131 268f45cc-cd09-0410-ab3c-d52691b4dbfc
writeHelperGetString in V8HTMLDocument uses += to concatenate strings
https://bugs.webkit.org/show_bug.cgi?id=93035

Patch by Jae Hyun Park <jae.park@company100.net> on 2012-08-08
Reviewed by Adam Barth.

Use a StringBuilder instead of String concatenation because StringBuilder is generally faster.

No new functionality, so no new tests.

* bindings/v8/custom/V8HTMLDocumentCustom.cpp:
(WebCore::writeHelperGetString):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125132 268f45cc-cd09-0410-ab3c-d52691b4dbfc
EventDispatcher::dispatchSimulatedClick should not reuse the same EventDispatcher instance.
https://bugs.webkit.org/show_bug.cgi?id=93452

Reviewed by Dimitri Glazkov.

This is a follow up patch after r124975.  There is yet another
place where the same EventDispatcher instance is reused across
event dispatching.

In addition to that, in order to simulate a real click, we must
different dispatchers because we must recalculate event ancestors
each time.  Current implementation wrongly freezes event ancestors
at the first event dispatching.

No new tests, no change in functionality.

* dom/EventDispatcher.cpp:
(WebCore::EventDispatcher::dispatchSimulatedClick):
(WebCore::EventDispatcher::EventDispatcher):
(WebCore::EventDispatcher::dispatchEvent):
* dom/EventDispatcher.h:
(EventDispatcher):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125133 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use char* instead of LChar* for the public interface of String construction from literals
https://bugs.webkit.org/show_bug.cgi?id=93402

Patch by Benjamin Poulain <bpoulain@apple.com> on 2012-08-08
Reviewed by Michael Saboff.

Source/JavaScriptCore: 

Update JSC' Identifier to use StringImpl::createFromLiteral with a char*.

* runtime/Identifier.cpp:
(JSC::IdentifierASCIIStringTranslator::translate):

Source/WTF: 

When the initialization from literal was added, some constructor/initialization function were
using LChar for convenience.

Since those function should only take ASCII characters, using LChar* could cause confusion. This
patch intents to clarify this by using char* for all those APIs.

* wtf/text/AtomicString.cpp:
(WTF::CharBufferFromLiteralDataTranslator::hash):
(WTF::CharBufferFromLiteralDataTranslator::equal):
(WTF::CharBufferFromLiteralDataTranslator::translate):
(WTF::AtomicString::addFromLiteralData):
* wtf/text/AtomicString.h:
(WTF::AtomicString::AtomicString):
(AtomicString):
* wtf/text/StringImpl.cpp:
(WTF::StringImpl::createFromLiteral):
* wtf/text/StringImpl.h:
(StringImpl):
(WTF::StringImpl::StringImpl):
(WTF::StringImpl::createFromLiteral):

Tools: 

* TestWebKitAPI/Tests/WTF/StringImpl.cpp:
(TestWebKitAPI::TEST):


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