AX: Need ability to get line range for text marker.
https://bugs.webkit.org/show_bug.cgi?id=130906

Reviewed by Chris Fleizach.

LayoutTests:

Added test to ensure we can get the correct range of a line from a given marker.
Also updated existing bounds-for-range test to include new attribute.

* platform/mac/accessibility/bounds-for-range-expected.txt:
* platform/mac/accessibility/line-range-for-text-marker-expected.txt: Added.
* platform/mac/accessibility/line-range-for-text-marker.html: Added.

Source/WebCore:

Added ability to get line range from any marker on that line. This matches the functionality of existing
attributes such as AXParagraphTextMarkerRangeForTextMarker and AXSentenceTextMarkerRangeForTextMarker.

Test: platform/mac/accessibility/line-range-for-text-marker.html

* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::visiblePositionRangeForRange):
(WebCore::AccessibilityObject::lineRangeForPosition):
* accessibility/AccessibilityObject.h:
* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityParameterizedAttributeNames]):
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):

Tools:

Added a new function in DRT and TestRunner to test that AXLineTextMarkerRangeForTextMarker works as expected.

* DumpRenderTree/AccessibilityUIElement.cpp:
(lineTextMarkerRangeForTextMarkerCallback):
(AccessibilityUIElement::lineTextMarkerRangeForTextMarker):
(AccessibilityUIElement::getJSClass):
* DumpRenderTree/AccessibilityUIElement.h:
* DumpRenderTree/mac/AccessibilityUIElementMac.mm:
(AccessibilityUIElement::lineTextMarkerRangeForTextMarker):
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
(WTR::AccessibilityUIElement::lineTextMarkerRangeForTextMarker):
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
* WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:
(WTR::AccessibilityUIElement::lineTextMarkerRangeForTextMarker):
* WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm:
(WTR::AccessibilityUIElement::lineTextMarkerRangeForTextMarker):
* WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::lineTextMarkerRangeForTextMarker):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166513 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Radio buttons and checkboxes should share code
https://bugs.webkit.org/show_bug.cgi?id=130915

Reviewed by Sam Weinig.

Radio buttons and checkboxes now share a lot of code. The common term for both is 
toggle buttons.

Move these radio-sizing functions up in the file to be next to the checkbox sizing 
functions.
* platform/mac/ThemeMac.mm:
(WebCore::radioSizes):
(WebCore::radioMargins):
(WebCore::radioSize):

Configures a radio button or a checkbox.
(WebCore::configureToggleButton):

Creates a radio button or a checkbox.
(WebCore::createToggleButtonCell):

Still have a shared cell for each.
(WebCore::sharedRadioCell):
(WebCore::sharedCheckboxCell):

Does the work of the old paintRadio() and paintCheckbox().
(WebCore::paintToggleButton):

Use sharedRadioCell() here.
(WebCore::ThemeMac::inflateControlPaintRect):

Call paintToggleButton() for radio buttons and checkboxes.
(WebCore::ThemeMac::paint):

All gone.
(WebCore::configureCheckbox): Deleted.
(WebCore::createCheckboxCell): Deleted.
(WebCore::paintCheckbox): Deleted.
(WebCore::radio): Deleted.
(WebCore::paintRadio): Deleted.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
run-webkit-tests should have a --no-timeout option
https://bugs.webkit.org/show_bug.cgi?id=128286

Patch by Jozsef Berta <jberta.u-szeged@partner.samsung.com> on 2014-03-31
Reviewed by Joseph Pecoraro.

* Scripts/webkitpy/layout_tests/controllers/layout_test_runner.py:
(Worker._run_test): Renaming _run_test_with_timeout()
(Worker._run_test_with_or_without_timeout): Renaming _run_test_with_timeout(), because tests can now run without timeout.
(Worker._run_test_in_another_thread): Passing the --no-timeout option to the driver
(Worker._run_test_in_this_thread):
(Worker._run_test_with_timeout): Deleted.
* Scripts/webkitpy/layout_tests/run_webkit_tests.py:
(parse_args): Added the --no-timeout option

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS WebKit2] Disable tile cohort retention for now
https://bugs.webkit.org/show_bug.cgi?id=130926
<rdar://problem/16465413>

Reviewed by Simon Fraser.

* WebCore.exp.in:
* page/Settings.cpp:
(WebCore::Settings::Settings):
(WebCore::Settings::setScrollingPerformanceLoggingEnabled):
(WebCore::Settings::setAggressiveTileRetentionEnabled): Deleted.
* page/Settings.h:
(WebCore::Settings::aggressiveTileRetentionEnabled): Deleted.
* page/Settings.in:
Use Settings.in for these simple settings.

* platform/graphics/GraphicsLayerClient.h:
(WebCore::GraphicsLayerClient::shouldAggressivelyRetainTiles):
(WebCore::GraphicsLayerClient::shouldTemporarilyRetainTileCohorts):
* platform/graphics/TiledBacking.h:
* platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::platformCALayerShouldAggressivelyRetainTiles):
(WebCore::GraphicsLayerCA::platformCALayerShouldTemporarilyRetainTileCohorts):
* platform/graphics/ca/GraphicsLayerCA.h:
* platform/graphics/ca/PlatformCALayerClient.h:
(WebCore::PlatformCALayerClient::platformCALayerShouldAggressivelyRetainTiles):
(WebCore::PlatformCALayerClient::platformCALayerShouldTemporarilyRetainTileCohorts):
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::shouldAggressivelyRetainTiles):
(WebCore::RenderLayerBacking::shouldTemporarilyRetainTileCohorts):
* rendering/RenderLayerBacking.h:
Plumb the two tile-retention settings through to TileController in a pull manner
instead of a push manner, as there were some cases (especially on iOS) where
the settings weren't always getting pushed down.

* platform/graphics/ca/mac/TileController.h:
* platform/graphics/ca/mac/TileController.mm:
(WebCore::TileController::TileController):
(WebCore::TileController::tileRevalidationTimerFired):
(WebCore::TileController::revalidateTiles):
(WebCore::TileController::drawTileMapContents):
Aggressive tile retention wins over temporary retention. If we aren't
using temporary (cohort) retention, throw away the cohort as soon as it
is created.

* Shared/WebPreferencesStore.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::updatePreferences):
Add a preference for temporary tile cohort retention (essentially, provide a setting
that means that we will never retain tiles at all once they leave the tile coverage rect).
Defaults to true to maintain existing behavior, except for iOS WebKit2, where
it defaults to false because we don't have the requisite support for purgeable tiles yet.

* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::updatePreferences):
(WebKit::TiledCoreAnimationDrawingArea::setRootCompositingLayer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Clarify some scrolling tree terminology
https://bugs.webkit.org/show_bug.cgi?id=130929

Reviewed by Tim Horton.

Attempt to reduce some ambiguity in scrolling tree terminology.
When async scrolling occurs, there are two tasks we have to perform:
1. Layers need to be updated to reflect the scroll
2. WebCore state has to be updated.
The "updateForViewport" name didn't clearly reflect which of these
tasks was being performed, so rename it to updateLayersAfterViewportChange()
to reflect the fact that it only does the first.

Remove the Mac implementation of updateLayersAfterViewportChange(), since
it was confsued about this, and was never called anyway.

* WebCore.exp.in:
* page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::viewportChangedViaDelegatedScrolling):
* page/scrolling/ScrollingTreeScrollingNode.h:
* page/scrolling/ios/ScrollingTreeScrollingNodeIOS.h:
* page/scrolling/ios/ScrollingTreeScrollingNodeIOS.mm:
(WebCore::ScrollingTreeScrollingNodeIOS::updateLayersAfterViewportChange):
(WebCore::ScrollingTreeScrollingNodeIOS::updateForViewport): Deleted.
* page/scrolling/mac/ScrollingTreeScrollingNodeMac.h:
* page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm:
(WebCore::ScrollingTreeScrollingNodeMac::updateLayersAfterViewportChange):
(WebCore::ScrollingTreeScrollingNodeMac::updateForViewport): Deleted.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166517 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix scrolling on OS X with UI-side compositing
https://bugs.webkit.org/show_bug.cgi?id=130930

Reviewed by Tim Horton.

On iOS, we rely on visible rect updates to propagate scroll offset
changes to the WebProcess. RemoteScrollingCoordinatorProxy was thus hardcoded
to bail from scrollPositionChanged() when the scrolled node was the root node,
but this broke OS X. Fix by adding a behavior flag to RemoteScrollingCoordinatorProxy.

* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::RemoteScrollingCoordinatorProxy):
(WebKit::RemoteScrollingCoordinatorProxy::scrollPositionChanged):
* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::setPropagatesMainFrameScrolls):
(WebKit::RemoteScrollingCoordinatorProxy::propagatesMainFrameScrolls):
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::initializeWebPage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@166518 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Attempt to fix the 32bits debug builds

The additional debug flags in RefCounted cause the structure to have different alignment
with the 64bits flags.

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-03-31

* rendering/style/RenderStyle.cpp:


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