WK1 WebFrameNetworkingContext cleanup: do not instanciate an empty NSString to create an empty WTF::String
https://bugs.webkit.org/show_bug.cgi?id=134222

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-06-24
Reviewed by Andreas Kling.

* WebCoreSupport/WebFrameNetworkingContext.mm:
(WebFrameNetworkingContext::sourceApplicationIdentifier):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170407 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] Adopt the C API of UIWebTouchEventsGestureRecognizer for touch event mapping
https://bugs.webkit.org/show_bug.cgi?id=134234

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-06-24
Reviewed by Tim Horton.

The C API is more efficient and expose properties we will need for other patches. This patch moves from
getting each value independently on UIWebTouchEventsGestureRecognizer to the single structure exposed
by _UIWebTouchEvent.

* Shared/NativeWebTouchEvent.h:
* Shared/ios/NativeWebTouchEventIOS.mm:
(WebKit::convertTouchPhase):
(WebKit::extractWebTouchPoint):
(WebKit::NativeWebTouchEvent::NativeWebTouchEvent):
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _webTouchEventsRecognized:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170408 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] We should not start potential tap activation unless the tap gesture recognizer succeed
https://bugs.webkit.org/show_bug.cgi?id=134277
<rdar://problem/17439973>

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-06-24
Reviewed by Anders Carlsson.

* UIProcess/ios/WKSyntheticClickTapGestureRecognizer.m:
(-[WKSyntheticClickTapGestureRecognizer setState:]):
We were calling the _gestureRecognizedAction even for failure states. The potential activation work
is not light on the Web Process, we should not start if we don't care about the result.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170409 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Win] Remove some out-of-date stuff from our instructions.
https://bugs.webkit.org/show_bug.cgi?id=134282

Reviewed by Tim Horton.

* building/build.html: Remove reference to "Platform SDK" which we don't manuall 
install anymore (it's part of Visual Studio 2013).
* building/tools.html: We no longer need QuickTime SDK, QuickTime Player, or
the DirectX SDK.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170410 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Speculative 32-bit Mac build fix after r170402.

* platform/graphics/mac/ComplexTextController.cpp:
(WebCore::advanceByCombiningCharacterSequence):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170411 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: Remove tight platform expectation coupling form roles-exposed layout test.
https://bugs.webkit.org/show_bug.cgi?id=134123

Reviewed by Chris Fleizach.

Don't enforce platform specific differences in the test itself. This is what the various expectation files are for.

* accessibility/roles-exposed-expected.txt:
* accessibility/roles-exposed.html:
* platform/mac-mountainlion/accessibility/roles-exposed-expected.txt:
* platform/mac/accessibility/roles-exposed-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170412 268f45cc-cd09-0410-ab3c-d52691b4dbfc
InlineTextBox's m_len can be an unsigned (rather than an unsigned short)
https://bugs.webkit.org/show_bug.cgi?id=134173

Reviewed by Daniel Bates.

After Zalan's talks with Kling, it seems that the simple line layout code
might alleviate the need for the space savings in InlineTextBox. Given this,
it would be beneficial to be a little more safe by using unsigneds throughout.

For example, we have code like "void setLen(unsigned len) { m_len = len; }"
which might silently break if given particular inputs.

No new tests because there is no behavior change.

* rendering/InlineTextBox.cpp:
(WebCore::InlineTextBox::isSelected):
(WebCore::InlineTextBox::localSelectionRect):
(WebCore::InlineTextBox::paint):
(WebCore::InlineTextBox::selectionStartEnd):
(WebCore::InlineTextBox::paintSelection):
(WebCore::InlineTextBox::paintCompositionBackground):
(WebCore::InlineTextBox::paintDocumentMarker):
(WebCore::InlineTextBox::paintTextMatchMarker):
(WebCore::InlineTextBox::computeRectForReplacementMarker):
* rendering/InlineTextBox.h:
(WebCore::InlineTextBox::truncation):
* rendering/RenderTextLineBoxes.cpp:
(WebCore::ellipsisRectForBox):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170413 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Tiles on bottom of screen are not always allocated when necessary
https://bugs.webkit.org/show_bug.cgi?id=134272

Reviewed by Simon Fraser.

Source/WebCore:
The initial visibleRect is in the coordinate of the root layer, so its origin
is at the top left of the view. The initial rect we were using doesn't
include the contents inset, so it was too short, which was causing tiles near
the bottom of the screen to not always be allocated if the tile threshold was
close to the bottom of the view. Instead, we want to include the contents
inset size so the visible rect includes the entire view.
GraphicsLayerCA::recursiveCommitChanges() takes care of mapping and cropping
the visible rect into the tiled layer's coordinate system, at which point it
is used for visible tile logic.

Test: platform/mac-wk2/tiled-drawing/visible-rect-content-inset.html

* platform/graphics/ca/TileCoverageMap.cpp:
(WebCore::TileCoverageMap::update):
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::flushPendingLayerChanges):

LayoutTests:
Apply a content inset, then dump visible rects.

* platform/mac-wk2/tiled-drawing/visible-rect-content-inset-expected.txt: Added.
* platform/mac-wk2/tiled-drawing/visible-rect-content-inset.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170414 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, update my speciality.

* Scripts/webkitpy/common/config/contributors.json:

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