Unreviewed: WebInspector: remove accidentally committed speed test.

* tests/MemoryInstrumentationTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127617 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Enable/disable composited scrolling based on overflow
https://bugs.webkit.org/show_bug.cgi?id=95323

Patch by Sami Kyostila <skyostil@google.com> on 2012-09-05
Reviewed by Simon Fraser.

Source/WebCore:

When an overflow:{auto,overlay} and -webkit-overflow-scrolling:touch
element gains or loses overflow, we should correspondingly enable and
disable composited scrolling depending on whether the element can be
scrolled or not.

The previous logic in RenderLayer::usesCompositedScrolling() already
checked for actual overflow, but we also need to recompute the
compositing requirements when the amount of overflow changes during
layout. Additionally, layers using composited scrolling are marked as
self-painting to ensure they are always promoted to composited layers
when needed.

Test: compositing/overflow/overflow-auto-with-touch-toggle.html

Note that the behavior for maintaining a stacking context even without
the presense of overflow is covered by platform/chromium/compositing/overflow/overflow-scrolling-touch-stacking-context.html.

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateScrollInfoAfterLayout):
(WebCore::RenderLayer::shouldBeSelfPaintingLayer):

LayoutTests:

Added a new test for making sure composited scrolling is enabled when overflow
is introduced.

Note that this test will pass only if OVERFLOW_SCROLLING is enabled.

* compositing/overflow/overflow-auto-with-touch-toggle-expected.txt: Added.
* compositing/overflow/overflow-auto-with-touch-toggle.html: Added.
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127620 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Remove getRenderStyleForStrike from PlatformSupport
https://bugs.webkit.org/show_bug.cgi?id=95363

Reviewed by Adam Barth.

Part of a refactoring series. See tracking bug 82948.

Source/Platform:

* Platform.gypi:
* chromium/public/linux/WebFontInfo.h: Added.
(WebKit):
(WebFontInfo):
* chromium/public/linux/WebFontRenderStyle.h: Added.
(WebKit):

Source/WebCore:

* platform/chromium/PlatformSupport.h:
(PlatformSupport):
* platform/graphics/harfbuzz/FontPlatformDataHarfBuzz.cpp:
(WebCore::FontPlatformData::operator==):
(WebCore::FontPlatformData::getRenderStyleForStrike):
(WebCore):
(WebCore::FontPlatformData::querySystemForRenderStyle):
* platform/graphics/harfbuzz/FontPlatformDataHarfBuzz.h:
(FontPlatformData):

Source/WebKit/chromium:

* public/linux/WebFontInfo.h:
* public/linux/WebFontRenderStyle.h:
* src/PlatformSupport.cpp:
(WebCore):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove use of JSCell::classInfoOffset() from virtualForThunkGenerator
https://bugs.webkit.org/show_bug.cgi?id=95821

Reviewed by Oliver Hunt.

We can replace the load of the ClassInfo from the object with a load from the Structure.

* dfg/DFGThunks.cpp:
(JSC::DFG::virtualForThunkGenerator):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127625 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Slider progress bar goes crazy with negative ranges
https://bugs.webkit.org/show_bug.cgi?id=95753

Patch by Thiago Marcos P. Santos <thiago.santos@intel.com> on 2012-09-05
Reviewed by Kenneth Rohde Christiansen.

Source/WebCore:

Now the calculation of what the current value represents in terms
of progress (from 0 to 1) is correctly done.

Test: fast/forms/range/input-range-progress-indicator.html

* platform/efl/RenderThemeEfl.cpp:
(WebCore::RenderThemeEfl::paintThemePart):

LayoutTests:

Added ref test to check if rendering results of sliders using
negative value ranges are coherent.

* fast/forms/range/input-range-progress-indicator-expected.html: Added.
* fast/forms/range/input-range-progress-indicator.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127626 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Rotation and then reload causes less sized webpage (PR 190469)
https://bugs.webkit.org/show_bug.cgi?id=95870

Reviewed by George Staikos.
Reviewed internally by Jacky Jiang.

Use the new zoom to fit scale if the page was zoomed to fit initial scale
When a page is reloaded the layout size may be changed. So the contents
size on which the initial scale depends may be changed. Use the new initial
scale in this case to make sure the page will be zoomed to correct scale.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127628 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Put webcore_platform_files in separate gyp target instead of relying on exclusion patterns
https://bugs.webkit.org/show_bug.cgi?id=95876

Reviewed by Tony Chang.

This puts the list of WebCore/platform files in a webcore_platform_files gyp variable instead of filtering by
path out of webcore_files. This simplifies the .gyp a bit and makes it possible to split this target up further.

* WebCore.gyp/WebCore.gyp:
* WebCore.gypi:

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