[Chromium] Test expectations for failing image tests following Chromium r166632.

Unreviewed gardening.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133913 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Rework the API to use document coordinates
https://bugs.webkit.org/show_bug.cgi?id=101608
RIM PR 173292

Reviewed by Adam Treat.

Source/WebCore:

Provide a better API for WebPage to relay.
See Source/WebKit/blackberry/ChangeLog for details.

* platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:
(WebCore::MediaPlayerPrivate::getWindowScreenRect):
* platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.h:
(Platform):
(BlackBerry):
(MediaPlayerPrivate):

Source/WebKit/blackberry:

Scrolling and zooming APIs used to operate on
transformed coordinates, which is a bad idea:
The UI thread might long have moved on to a
different scale and scroll position so outdated
pixel coordinates are of limited value.

Moreover, more transformation calculations are
needed than if we operate purely on document
coordinates.

With webkitThreadViewportAccessor() exposed,
the caller has a choice between how to handle
coordinates and the means to perform conversions
with little effort and overhead if needed.
Therefore, we should remove pixel coordinates
from the public API. This commit makes this change.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::repaint):
(BlackBerry::WebKit::BackingStorePrivate::didRenderContent):
* Api/InRegionScroller.cpp:
(BlackBerry::WebKit::InRegionScroller::setDocumentScrollPositionCompositingThread):
(BlackBerry::WebKit::InRegionScroller::setDocumentScrollPositionWebKitThread):
(BlackBerry::WebKit::InRegionScrollerPrivate::calculateInRegionScrollableAreasForPoint):
* Api/InRegionScroller.h:
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
(BlackBerry::WebKit::WebPagePrivate::setLoadState):
(BlackBerry::WebKit::WebPagePrivate::shouldZoomAboutPoint):
(BlackBerry::WebKit::WebPagePrivate::zoomAboutPoint):
(BlackBerry::WebKit::WebPage::setDocumentScrollPosition):
(BlackBerry::WebKit::WebPagePrivate::hasVirtualViewport):
(BlackBerry::WebKit::WebPagePrivate::notifyTransformedContentsSizeChanged):
(BlackBerry::WebKit::WebPagePrivate::notifyTransformedScrollChanged):
(BlackBerry::WebKit::WebPagePrivate::setCursor):
(BlackBerry::WebKit::WebPagePrivate::notifyPopupAutofillDialog):
(BlackBerry::WebKit::WebPagePrivate::fixedLayoutSize):
(BlackBerry::WebKit::WebPagePrivate::bestNodeForZoomUnderPoint):
(BlackBerry::WebKit::WebPagePrivate::blockZoomRectForNode):
(BlackBerry::WebKit::WebPagePrivate::zoomBlock):
(BlackBerry::WebKit::WebPage::setVirtualViewportSize):
(BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments):
(BlackBerry::WebKit::WebPagePrivate::dispatchViewportPropertiesDidChange):
(BlackBerry::WebKit::WebPagePrivate::resumeBackingStore):
(BlackBerry::WebKit::WebPagePrivate::setViewportSize):
(BlackBerry::WebKit::WebPage::setDefaultLayoutSize):
(BlackBerry::WebKit::WebPagePrivate::setScrollOriginPoint):
(BlackBerry::WebKit::WebPage::setDocumentScrollOriginPoint):
(BlackBerry::WebKit::handleScrolling):
(BlackBerry::WebKit::WebPage::selectionContainsDocumentPoint):
(BlackBerry::WebKit::WebPage::setDocumentSelection):
(BlackBerry::WebKit::WebPage::setDocumentCaretPosition):
(BlackBerry::WebKit::WebPage::selectAtDocumentPoint):
(BlackBerry::WebKit::WebPagePrivate::setTextReflowAnchorPoint):
(BlackBerry::WebKit::WebPage::pinchZoomAboutPoint):
(BlackBerry::WebKit::WebPage::blockZoom):
(BlackBerry::WebKit::WebPage::nodeAtDocumentPoint):
(BlackBerry::WebKit::WebPagePrivate::enterFullscreenForNode):
* Api/WebPage.h:
(Platform):
* Api/WebPageClient.h:
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/AutofillManager.cpp:
(WebCore::AutofillManager::didChangeInTextField):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidLayout):
* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::selectionPositionChanged):
(BlackBerry::WebKit::SelectionHandler::caretPositionChanged):

Tools:

Adapt to changed WebPage API.
See Source/WebKit/blackberry/ChangeLog for details.

* DumpRenderTree/blackberry/DumpRenderTree.cpp:
(BlackBerry::WebKit::DumpRenderTree::DumpRenderTree):
(BlackBerry::WebKit::DumpRenderTree::resetToConsistentStateBeforeTesting):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133914 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: show statistics over selected frame range in Timeline's Frame mode
https://bugs.webkit.org/show_bug.cgi?id=101593

Reviewed by Pavel Feldman.

- change status bar records counter wording to "N of M frames|records shown" depending on mode;
- append average frame length and & stddev in frame mode;
- expand the above to a popover that includes frame count, range duration and min/avg/max/stddev on frame length;
- show frame bars & dividers iff selection range includes < 30 frames (drive-by)

* English.lproj/localizedStrings.js:
* inspector/front-end/TimelineFrameController.js:
(WebInspector.FrameStatistics):
* inspector/front-end/TimelineModel.js:
(WebInspector.TimelineModel.aggregateTimeByCategory):
* inspector/front-end/TimelinePanel.js:
(WebInspector.TimelinePanel.prototype.get statusBarItems):
(WebInspector.TimelinePanel.prototype._createStatusBarItems.getAnchor):
(WebInspector.TimelinePanel.prototype._createStatusBarItems):
(WebInspector.TimelinePanel.prototype._updateRecordsCounter):
(WebInspector.TimelinePanel.prototype._updateFrameStatistics):
(WebInspector.TimelinePanel.prototype._showFrameStatistics):
(WebInspector.TimelinePanel.prototype._updateFrameBars):
(WebInspector.TimelinePanel.prototype._overviewModeChanged.set if):
(WebInspector.TimelinePanel.prototype._overviewModeChanged):
(WebInspector.TimelinePanel.prototype._refresh):
* inspector/front-end/TimelinePresentationModel.js:
(WebInspector.TimelinePresentationModel.prototype.):
(WebInspector.TimelinePresentationModel.prototype.compareEndTime):
(WebInspector.TimelinePresentationModel.prototype.filteredFrames):
(WebInspector.TimelinePresentationModel.generatePopupContentForFrameStatistics):
* inspector/front-end/timelinePanel.css:
(.timeline-records-stats, .storage-application-cache-status, .storage-application-cache-connectivity):
(.timeline-records-stats):
(.timeline-frames-stats):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133915 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Cleanup IDBBindingUtilitiesTest
https://bugs.webkit.org/show_bug.cgi?id=100860

Patch by Dan Carney <dcarney@google.com> on 2012-11-08
Reviewed by Adam Barth.

Small cleanup of IDBBindingUtilitiesTest as per
https://bugs.webkit.org/show_bug.cgi?id=99975#c38

* tests/IDBBindingUtilitiesTest.cpp:
(IDBKeyFromValueAndKeyPathTest):
(WebKit::IDBKeyFromValueAndKeyPathTest::IDBKeyFromValueAndKeyPathTest):
(WebKit::IDBKeyFromValueAndKeyPathTest::context):
(WebKit):
(WebKit::TEST_F):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133916 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Multiple Layout Tests (e.g. fast/repaint/japanese-rl-selection-clear.html) is failing after r133840.
https://bugs.webkit.org/show_bug.cgi?id=101547

[Chromium] Unreviewed gardening - test expectations update.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133917 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HashAndUTF8CharactersTranslator should create an 8 bit string if possible
https://bugs.webkit.org/show_bug.cgi?id=101515

Reviewed by Darin Adler.

Added isAllASCII flag that's passed to convertUTF8ToUTF16().  If on return it is true, create an
8 bit string, otherwise use the 16 bit string.

* wtf/text/AtomicString.cpp:
(WTF::HashAndUTF8CharactersTranslator::translate):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133918 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Unreviewed gardening - fix lint failures in expectations file.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133919 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. More gardening after r133898.

* platform/efl/TestExpectations:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133920 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Optimized kerning and ligatures using caching
https://bugs.webkit.org/show_bug.cgi?id=101269

Reviewed by Dan Bernstein.

Consider three kinds of text layout, and the value of caching for each:

    (1) 1 layout of 100% unique words: small negative value.

    (2) 1 layout of English prose: medium positive value.

    (3) Many layouts of anything: extra-extra-large positive value.

Since we can't distinguish betwen these workflows a priori, we use statistical
sampling. To minimize cost in (1) and maximize benefit in (2) and (3), we treat
each cache access as a statistical sample, and use the cache in proportion to
the observed probability of duplicate text measurement.

Benchmark results:
    plt3: 1% faster
    chapter-reflow-once-random: No change [*]
    chapter-reflow-once: 23% faster
    chapter-reflow-twice: 52% faster
    chapter-reflow-thrice: 68% faster
    chapter-reflow: 263% faster
    line-layout: 270% faster

    [*] This is a stress test designed to make everything go wrong for
    caching. It does not represent real world content.

* GNUmakefile.list.am:
* Target.pri:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* platform/graphics/WidthCache.h: Added.

(WidthCache): Added a class that caches common word widths. This cache
could cache more things or more cases in future -- but for now it seems
to cover the common cases.

(SmallStringKey): Early profiling showed that allocating an AtomicString
or String measurably added to the cost of the cache, so I added a custom
string key that can be stored directly inside the table by value --
empirically answering an age-old question with which Apple WebKit engineers
seem to be obsessed.

(WebCore::WidthCache::SmallStringKey::capacity):
(WebCore::WidthCache::SmallStringKey::SmallStringKey):
(WebCore::WidthCache::SmallStringKey::characters):
(WebCore::WidthCache::SmallStringKey::length):
(WebCore::WidthCache::SmallStringKey::hash):
(WebCore::WidthCache::SmallStringKey::isHashTableDeletedValue):
(WebCore::WidthCache::SmallStringKey::isHashTableEmptyValue):
(WebCore::WidthCache::SmallStringKeyHash::hash):
(WebCore::WidthCache::SmallStringKeyHash::equal):
(SmallStringKeyHash):
(SmallStringKeyHashTraits):
(WebCore::WidthCache::SmallStringKeyHashTraits::isEmptyValue): Ditto.

(WebCore::WidthCache::WidthCache):
(WebCore::WidthCache::add): Separate out the "don't use the cache" case
so the compiler can inline it separate, hopefully further reducing cases
of (1).

(WebCore::WidthCache::addSlowCase): There's a little subtlety to the
sampling policy here. Lots of different approaches are possible, and I
just picked a simple one that seemed to work based on benchmarking. I'll
point out some interesting sublteties I'm aware of here:

    (*) Since we start at the min sampling rate, a font used for 20 words
    or fewer never allocates a cache. Anecdotally, some fonts seem to
    be used this way.

    (*) When the sampling rate is x / y, sampling all x words in a row
    seems smart because some words may occur more commonly in relation to
    each other (such as 'each' and 'other'), and repeat workloads will
    lay out the same words in order. Intuitively, these are both reasons
    this policy may ramp up more effectively under load.

    (*) I opted for linear back-off instead of, say, exponential back-off
    because we're not trying to back off to infinity -- just to our min
    sampling rate. Since we don't expect the cache to hit for every word,
    my guess is that exponential back-off would be too aggressive.

    (*) Our "eviction" policy has an IQ of 1. I expect this is sufficient
    because it would be surprising to see a million unique words all used
    in the same document. (I would not like to play a Letterpress game
    against such a document.)

(WebCore::WidthCache::clear): Needed because a font can change, in which
case we need to ditch its cache.

(WebCore::operator==): Needed for hashing.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133921 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Unreviewed gardening - widen flaky expectation to include crash

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133922 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Mac build fix: Mark WidthCache.h 'private' so WebKit can use it.

Not reviewed.

* WebCore.xcodeproj/project.pbxproj:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133923 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Increase memory cache size
https://bugs.webkit.org/show_bug.cgi?id=101622

Reviewed by Yong Li.

* WebCoreSupport/CacheClientBlackBerry.cpp:
(WebCore::CacheClientBlackBerry::updateCacheCapacity):
* WebCoreSupport/CacheClientBlackBerry.h:
(CacheClientBlackBerry):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Create loader/blackberry directory, because svn-apply cannot apply a patch that
        creates a directory and moves a file into it.

        * loader/blackberry: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133925 268f45cc-cd09-0410-ab3c-d52691b4dbfc
4.68MB below RenderStyle::filter() on Membuster3.
<http://webkit.org/b/101624>
<rdar://problem/12663822>

Reviewed by Darin Adler.

Rename the non-const RenderStyle::filter() to mutableFilter() since using it causes us to detach
from the rare non-inherited data (copy-on-write.)
Most call sites were calling filter() on a RenderStyle* which was causing the bloat.

4.68MB progression on Membuster3.

* css/StyleResolver.cpp:
(WebCore::StyleResolver::loadPendingSVGDocuments):
(WebCore::StyleResolver::loadPendingShaders):
* rendering/style/RenderStyle.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133926 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Introduce WebScreenInfo.deviceScaleFactor
https://bugs.webkit.org/show_bug.cgi?id=101613

Patch by Sami Kyostila <skyostil@chromium.org> on 2012-11-08
Reviewed by Adam Barth.

Introduce the WebScreenInfo.deviceScaleFactor property, which specifies the
ratio between physical and logical pixels. This is the first step in replacing
horizontalDPI/verticalDPI in favor of the deviceScaleFactor.

For now, this value is only initialized on Mac, because the other ports that
use it initialize the value in Chromium, whereas Windows and X11 default to a
factor of 1. The value on Mac is truncated to an integer to match the
expectation in Chromium's RenderWidget.

Source/Platform:

* chromium/public/WebScreenInfo.h:
(WebScreenInfo):
(WebKit::WebScreenInfo::WebScreenInfo):

Source/WebKit/chromium:

* src/mac/WebScreenInfoFactory.mm:
(WebKit::WebScreenInfoFactory::screenInfo):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133927 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Janitor: Remove unused m_isValid bool
https://bugs.webkit.org/show_bug.cgi?id=101610

Reviewed by Rob Buis.

It's not used anywhere, but as we have a constructor
that creates an invalid TileIndex, let's add another
method to check validity - now a correct check.

On top of that, make the stylebot happy by reducing
"unsigned int" to just "unsigned".

* WebKitSupport/TileIndex.h:
(BlackBerry::WebKit::TileIndex::TileIndex):
(BlackBerry::WebKit::TileIndex::i):
(BlackBerry::WebKit::TileIndex::j):
(BlackBerry::WebKit::TileIndex::setIndex):
(BlackBerry::WebKit::TileIndex::isValid):
(TileIndex):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133928 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Roll WebKitSystemInterface DEPS.

Rubber-stamped by Andreas Kling.

* libWebKitSystemInterfaceLion.a:
* libWebKitSystemInterfaceMountainLion.a:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133929 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Even more gardening after r133898.

* platform/efl/TestExpectations:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133930 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed.  Rolled DEPS.

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-11-08

* DEPS:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@133931 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Wrong error type is thrown for type errors in callbacks
https://bugs.webkit.org/show_bug.cgi?id=101502

Reviewed by Adam Barth.

We should be throwing a TypeError and not a DOMException with code TYPE_MISMATCH_ERR.

http://www.w3.org/TR/WebIDL/#es-callback-function

Source/WebCore:

Updated existing tests.

* bindings/scripts/CodeGeneratorJS.pm:
* bindings/scripts/CodeGeneratorV8.pm:
* bindings/scripts/test/JS/JSTestObj.cpp:
* bindings/scripts/test/V8/V8TestObj.cpp:

LayoutTests:

* fast/mediastream/argument-types-expected.txt:
* fast/mediastream/peerconnection-argument-types-expected.txt:
* fast/mediastream/script-tests/argument-types.js:
* fast/mediastream/script-tests/peerconnection-argument-types.js:
* fast/workers/storage/open-database-inputs-sync-expected.txt:


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