[Qt][CSS Regions] fast/regions/overflow-size-change-with-stacking-context.html fails
https://bugs.webkit.org/show_bug.cgi?id=97199

Unreviewed, Qt Gardening.

Unskip test that is now passing on the bots.

Patch by Javier Fernandez <jfernandez@igalia.com> on 2013-06-12

* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151502 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Smarter algorithm to determine the backingstore rect
https://bugs.webkit.org/show_bug.cgi?id=117451

JIRA115644
https://jira.bbqnx.net/browse/BRWSR-7028

Patch by Jakob Petsovits <jpetsovits@blackberry.com> on 2013-06-12
Reviewed by Rob Buis.

So far, the backingstore tile geometry allocation was
pretty straightforward: We would start off from the
current viewport and append all available tiles into
the current scrolling direction from there.

This will usually work well enough, but has the downside
of discarding all the tiles in the opposite direction.
Also, tiles very close to the viewport will often get
discarded even if the user only scrolls very slowly.

This patch completely revamps the algorithm for
determining where the backingstore should be positioned.

The general idea is that we construct a "desired rect"
based on the viewport and inflate it into all four
directions according to the current scroll momentum.
This rectangle will be similarly large as a backingstore
tile geometry rectangle might be, by using the
approximate number of pixels that are available in the
given number of tiles.

The proportions for extending the rectangle from the
viewport are influenced by different factors, including
scroll momentum, viewport ratio, available space in the
overall contents rectangle, and natural bias for the
"down" direction.

In practice, this results in a backingstore that is
roughly evenly distributed around the viewport when no
movement is happening, and will gradually narrow down
and extend into the scroll direction at a higher momentum.

The final tile geometry is constructed by trying fit
the tiles into the desired rect in a way that maximizes
the area of its intersection. There are a few parameters
that can be tweaked, the ones in this patch seem to
handle most cases well enough to minimize checkerboarding.

As an additional bonus, a rectangle-based tiling strategy
can more easily be adopted for accelerated compositing,
which currently operates on a simpler algorithm that also
inflates the viewport but does not take scrolling into
account.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::BackingStorePrivate):
(BlackBerry::WebKit::BackingStorePrivate::expandedContentsSize):
(WebKit):
(BlackBerry::WebKit::BackingStorePrivate::nonOverscrolled):
(BlackBerry::WebKit::BackingStorePrivate::enclosingTileRect):
(BlackBerry::WebKit::BackingStorePrivate::desiredBackingStoreRect):
(BlackBerry::WebKit::BackingStorePrivate::mergeDesiredBackingStoreRect):
(BlackBerry::WebKit::BackingStorePrivate::largestTileRectForDesiredRect):
(BlackBerry::WebKit::BackingStorePrivate::scrollBackingStore):
(BlackBerry::WebKit::BackingStorePrivate::createSurfaces):
* Api/BackingStore_p.h:
(BackingStorePrivate):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151503 268f45cc-cd09-0410-ab3c-d52691b4dbfc
window.find() case-insensitive search doesn't match diacritical marks
https://bugs.webkit.org/show_bug.cgi?id=117353
<rdar://problem/8535227>

Patch by Daniel Bates <dabates@apple.com> on 2013-06-12
Reviewed by Darin Adler.

Source/WebCore:

Currently, a case-insensitive window.find() search will return true for a word w
(e.g. café) with diacritical characters when w appears on the page without
diacritical marks (e.g. cafe). This leads to bad results, especially when
searching for a non-English word (e.g. qué) where the presence of an accented
character(s) may change the meaning of the word. Instead window.find() should
return false when case-insensitively matching a word with diacritical marks to
the same word without diacritical marks.

Test: fast/text/find-diacritical-mark.html

* editing/TextIterator.cpp:
(WebCore::SearchBuffer::SearchBuffer):

LayoutTests:

Added test to use window.find() to find a search string in text, where either
the search string or text (or both) contain diacritical characters.

Additionally, updated tests LayoutTests/fast/text/find-soft-hyphen.html
and LayoutTests/editing/execCommand/findString-diacriticals.html based on the
new behavior of window.find(). Moved function testFind() from LayoutTests/fast/text/script-tests/find-backwards.js
to its own file, LayoutTests/fast/text/resources/test-find.js, so that this function can
be used by both tests LayoutTests/fast/text/find-{backwards, diacritical-mark}.html.

* LayoutTests/editing/execCommand/findString-diacriticals.html: Update test based on the new
behavior of window.find().
* fast/text/find-backwards.html: Include external JavaScript file test-find.js.
* fast/text/find-case-folding-expected.txt: Rebase result; expected failure.
* fast/text/find-case-folding.html: Add comment to see bug #117548 with regards to expected failure.
* fast/text/find-diacritical-mark-expected.txt: Added.
* fast/text/find-diacritical-mark.html: Copied from LayoutTests/fast/text/find-backwards.html.
* fast/text/find-soft-hyphen-expected.txt: Rebase result.
* fast/text/resources/test-find.js: Added.
(testFind):
* fast/text/script-tests/find-backwards.js: Moved function testFind() from here to
file fast/text/resources/test-find.js and modified it to take an additional argument to
toggle search case sensitivity.
* fast/text/script-tests/find-diacritical-mark.js: Added.
* fast/text/script-tests/find-soft-hyphen.js: Update test based on the new behavior of window.find().

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151505 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[css exclusions] fast/css/variables/var-inside-shape.html is failing
https://bugs.webkit.org/show_bug.cgi?id=116059

Reviewed by Alexandru Chiculita.

Some shapes were incorrectly defined, there was a "rectange"
instead of a "rectangle" and also the number of parameters and
their types was wrong. Apart from that, both the CSS exclusions
and CSS variables settings were not enabled at runtime.

Some extra text was also added to the divs in order to verify that
the CSS exclusions are working properly.

* fast/css/variables/var-inside-shape-expected.html:
* fast/css/variables/var-inside-shape.html:
* platform/efl/TestExpectations: Removed var-inside-shape.html.
* platform/gtk/TestExpectations: Ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Remove dead WebDOM code
https://bugs.webkit.org/show_bug.cgi?id=113370

Patch by Alberto Garcia <agarcia@igalia.com> on 2013-06-12
Reviewed by Anders Carlsson.

BlackBerry PR 347565
Internally reviewed by Charles Wei.

.:

* Source/cmake/OptionsBlackBerry.cmake:

Source/WebCore:

* PlatformBlackBerry.cmake:

Source/WebKit/blackberry:

* Api/WebPage.cpp:
* Api/WebPage.h:
* WebCoreSupport/AboutDataEnableFeatures.in:
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:

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