[BlackBerry] Fix all flicker caused by empty/incomplete geometries.
https://bugs.webkit.org/show_bug.cgi?id=108951
RIM PR 286925

Reviewed by Rob Buis.
Internally reviewed by Arvid Nilsson.

The main idea for this patch is that whenever we adopt
a new backingstore geometry that doesn't contain any
rendered tiles, or VisibleZoom render jobs that need more
tiles to be rendered to be considered complete, we'll then
suspend blitting until there is valid content to show.

This main idea is codified as checks for empty buffers
in adoptAsFrontState(), and checks for the current state
of the render queue after rendering content in render().
However, as BackingStore objects with disabled surface pools
or pure use of accelerated compositing also swap geometries
in some circumstances, the use of suspend counters grows
increasingly fragile.

To make this patch more resilient against regressions,
the current suspend counter is complemented with several
explicit conditions for suspending screen updates,
and both subsequently combined into a single cached
boolean value telling the UI thread whether or not to
suspend. In the future, other suspend calls can be
migrated to this "state machine" design as well,
potentially phasing out the suspend counter altogether.

The immediate result is that there will be no flashing
of background color between page loads or after discarding
tiles on scale changes until the content has been rendered.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::BackingStorePrivate):
(BlackBerry::WebKit::BackingStorePrivate::suspendBackingStoreUpdates):
(BlackBerry::WebKit::BackingStorePrivate::suspendScreenUpdates):
(BlackBerry::WebKit::BackingStorePrivate::resumeBackingStoreUpdates):
(BlackBerry::WebKit::BackingStorePrivate::resumeScreenUpdates):
(BlackBerry::WebKit::BackingStorePrivate::updateSuspendScreenUpdateState):
(WebKit):
(BlackBerry::WebKit::BackingStorePrivate::render):
(BlackBerry::WebKit::BackingStorePrivate::blitVisibleContents):
(BlackBerry::WebKit::BackingStorePrivate::adoptAsFrontState):
(BlackBerry::WebKit::BackingStorePrivate::setCurrentBackingStoreOwner):
(BlackBerry::WebKit::BackingStore::releaseOwnedBackingStoreMemory):
* Api/BackingStore_p.h:
(BackingStorePrivate):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::setVisible):
(BlackBerry::WebKit::WebPagePrivate::setCompositorDrawsRootLayer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142137 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: [Regression] breakpoint condition not editable
https://bugs.webkit.org/show_bug.cgi?id=109183

Patch by Andrey Lushnikov <lushnikov@chromium.org> on 2013-02-07
Reviewed by Vsevolod Vlasov.

Improve TextEditorMainPanel.selection() method to return null if the
selection is set inside of decoration element.

No new tests.

* inspector/front-end/DOMExtension.js:
(Node.prototype.enclosingNodeOrSelfWithClass): Improve to add iteration boundary.
* inspector/front-end/DefaultTextEditor.js:
(WebInspector.TextEditorMainPanel.prototype.selection):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142138 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't ASSERT things about uninitialized variables.
https://bugs.webkit.org/show_bug.cgi?id=109187

Reviewed by Jochen Eisinger.

Rather than ASSERTing that an uninitialized ExceptionCode is non-zero
after some method executes, we should use the ASSERT_NO_EXCEPTION macro.

* editing/markup.cpp:
(WebCore::removeElementPreservingChildren):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142139 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Scrollbars misplaced with accelerated compositing for overflow scroll
https://bugs.webkit.org/show_bug.cgi?id=108625

Reviewed by Simon Fraser.

Source/WebCore:

Scrollbars require their own layer if overflow scroll is composited,
otherwise the scrollbars would be rendered on the content layer and
not fixed to the viewport.

* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::requiresHorizontalScrollbarLayer):
(WebCore::RenderLayerBacking::requiresVerticalScrollbarLayer):
(WebCore::RenderLayerBacking::requiresScrollCornerLayer):

LayoutTests:

Update the results for the one test that explicitly set accelerated compositing for overflow scroll,
and used to have bad results for non-chromium. The new baselines are almost identical to chomium baseline.

* platform/mac/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt:
* platform/qt/compositing/overflow/composited-scrolling-creates-a-stacking-container-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142140 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r142112.
http://trac.webkit.org/changeset/142112
https://bugs.webkit.org/show_bug.cgi?id=108990

The new test scrollingcoordinator/non-fast-scrollable-region-transformed- iframe.html crashes on Lion.

See http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=scrollingcoordinator%2Fnon-fast-scrollable-region-transformed-iframe.html

.:

* ManualTests/remove-fixed-position-but-keep-compositing.html: Removed.

Source/WebCore:

* CMakeLists.txt:
* Target.pri:
* WebCore.pri:
* page/scrolling/ScrollingCoordinator.cpp:
(WebCore::ScrollingCoordinator::create):
* page/scrolling/coordinatedgraphics/ScrollingCoordinatorCoordinatedGraphics.cpp: Removed.
* page/scrolling/coordinatedgraphics/ScrollingCoordinatorCoordinatedGraphics.h: Removed.
* platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::flushCompositingState):
* platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayerClient):
(WebCore::CoordinatedGraphicsLayer::setFixedToViewport):

Source/WebKit2:

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:
(WebKit::updateOffsetFromViewportForSelf):
(WebKit):
(WebKit::updateOffsetFromViewportForLayer):
(WebKit::CoordinatedLayerTreeHost::syncFixedLayers):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:
* WebProcess/WebPage/DrawingAreaImpl.cpp:
(WebKit::DrawingAreaImpl::DrawingAreaImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142141 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: home button behaviour is wrong in DTE
https://bugs.webkit.org/show_bug.cgi?id=109154

Patch by Andrey Lushnikov <lushnikov@chromium.org> on 2013-02-07
Reviewed by Vsevolod Vlasov.

Source/WebCore:

Handle home key shortcut explicitly in TextEditorMainPanel.

New test: inspector/editor/text-editor-home-button.html

* inspector/front-end/DefaultTextEditor.js:
(WebInspector.TextEditorMainPanel.prototype._registerShortcuts):
(WebInspector.TextEditorMainPanel.prototype._handleHomeKey):

LayoutTests:

Add layout test to verify home button behaviour. Exclude this test on
platforms that do not have eventSender object in test shell.

* inspector/editor/text-editor-home-button-expected.txt: Added.
* inspector/editor/text-editor-home-button.html: Added.
* platform/efl/TestExpectations:
* platform/mac/TestExpectations:
* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142142 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r142141.
http://trac.webkit.org/changeset/142141
https://bugs.webkit.org/show_bug.cgi?id=108990

Reland r142112, will update Chromium expectations and create a
Chromium bug instead for the crash.

.:

* ManualTests/remove-fixed-position-but-keep-compositing.html: Added.

Source/WebCore:

* CMakeLists.txt:
* Target.pri:
* WebCore.pri:
* page/scrolling/ScrollingCoordinator.cpp:
(WebCore::ScrollingCoordinator::create):
* page/scrolling/coordinatedgraphics/ScrollingCoordinatorCoordinatedGraphics.cpp: Added.
(WebCore):
(WebCore::ScrollingCoordinatorCoordinatedGraphics::ScrollingCoordinatorCoordinatedGraphics):
(WebCore::ScrollingCoordinatorCoordinatedGraphics::setLayerIsFixedToContainerLayer):
* page/scrolling/coordinatedgraphics/ScrollingCoordinatorCoordinatedGraphics.h: Added.
(WebCore):
(ScrollingCoordinatorCoordinatedGraphics):
* platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::setFixedToViewport):
(WebCore):
(WebCore::CoordinatedGraphicsLayer::flushCompositingState):
* platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayerClient):
(CoordinatedGraphicsLayer):

Source/WebKit2:

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:
* WebProcess/WebPage/DrawingAreaImpl.cpp:
(WebKit::DrawingAreaImpl::DrawingAreaImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142143 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Add settings checkbox for composited layer borders
https://bugs.webkit.org/show_bug.cgi?id=109096

Patch by Eberhard Graether <egraether@google.com> on 2013-02-07
Reviewed by Pavel Feldman.

This change adds a checkbox to show composited layer borders to the WebInspector's
rendering settings and plumbs the setting to Chromium's WebLayerTreeView. The setting
is visible if InspectorClient::canShowDebugBorders() returns true.

Source/Platform:

* chromium/public/WebLayerTreeView.h:
(WebLayerTreeView):
(WebKit::WebLayerTreeView::setShowDebugBorders):

Source/WebCore:

No new tests.

* English.lproj/localizedStrings.js:
* inspector/Inspector.json:
* inspector/InspectorClient.h:
(WebCore::InspectorClient::canShowDebugBorders):
(WebCore::InspectorClient::setShowDebugBorders):
(InspectorClient):
* inspector/InspectorPageAgent.cpp:
(PageAgentState):
(WebCore::InspectorPageAgent::restore):
(WebCore::InspectorPageAgent::disable):
(WebCore::InspectorPageAgent::canShowDebugBorders):
(WebCore):
(WebCore::InspectorPageAgent::setShowDebugBorders):
* inspector/InspectorPageAgent.h:
* inspector/front-end/Settings.js:
* inspector/front-end/SettingsScreen.js:
(WebInspector.GenericSettingsTab):
(WebInspector.GenericSettingsTab.prototype.get _showDebugBordersChanged):
* inspector/front-end/inspector.js:
(WebInspector.doLoadedDone):

Source/WebKit/chromium:

* src/InspectorClientImpl.cpp:
(WebKit::InspectorClientImpl::canShowDebugBorders):
(WebKit):
(WebKit::InspectorClientImpl::setShowDebugBorders):
* src/InspectorClientImpl.h:
(InspectorClientImpl):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::WebViewImpl):
(WebKit::WebViewImpl::setShowDebugBorders):
(WebKit):
(WebKit::WebViewImpl::setIsAcceleratedCompositingActive):
* src/WebViewImpl.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: linkifyResourceAsNode produced anchor should not prefer resources to scripts panel.
https://bugs.webkit.org/show_bug.cgi?id=109197

Reviewed by Pavel Feldman.

Javascript syntax errors in console are now linkified so that they show sources panel by default.

* inspector/front-end/ResourceUtils.js:
(WebInspector.linkifyResourceAsNode):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142145 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Invalid code is generated for storing constants with baseindex addressing modes on ARM traditional.
https://bugs.webkit.org/show_bug.cgi?id=109050

Reviewed by Oliver Hunt.

The S! scratch register is reused, but it should contain the constant value.

* assembler/ARMAssembler.cpp:
(JSC::ARMAssembler::baseIndexTransfer32):
(JSC::ARMAssembler::baseIndexTransfer16):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142146 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(r142003): Duplicate "Unknown" strings in LocalizedStrings.cpp not distinguished
by key
https://bugs.webkit.org/show_bug.cgi?id=109196

Reviewed by Eric Carlson.

* English.lproj/Localizable.strings:
Updated for the changes.
* platform/LocalizedStrings.cpp:
(WebCore::unknownFileSizeText):
Add a key.
(WebCore::textTrackNoLabelText):
Ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142147 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Remove unused workspace field from NetworkUISourceCodeProvider
https://bugs.webkit.org/show_bug.cgi?id=109201

Reviewed by Pavel Feldman.

Source/WebCore:

* inspector/front-end/NetworkUISourceCodeProvider.js:
(WebInspector.NetworkUISourceCodeProvider):
* inspector/front-end/inspector.js:

LayoutTests:

* inspector/debugger/network-uisourcecode-provider.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Add WebKitCSSFilterRule to DOMWindow.idl
https://bugs.webkit.org/show_bug.cgi?id=109082

Source/WebCore:

Reviewed by Dean Jackson.

Add an entry for WebKitCSSFilterRuleConstructor in DOMWindow.idl.

Tests: css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid.html
       css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid.html

* page/DOMWindow.idl:

LayoutTests:

Move the at-rule parsing tests to the recently added folder named
"custom-with-at-rule-parsing".

Remove the "custom-filter" prefix from the test filenames to
match the new convention.

Update the tests to use the "shouldHaveConstructor" JS helper function instead of the
"shouldBeType" JS helper function. Among other things, using "shouldHaveConstructor" tests
that window.WebKitCSSFilterRule is defined. "shouldHaveConstructor" has the same
behavior in JSC and V8, unlike "shouldBeType". Therefore, remove the Chromium-specific text
expectation file that was previously needed for "shouldBeType".

Reviewed by Dean Jackson.

* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid-expected.txt: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-invalid-expected.txt.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid.html: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-invalid.html.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid-expected.txt: Added.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid.html: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-valid.html.
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-at-rule-invalid.js: Renamed from LayoutTests/css3/filters/script-tests/custom-filter-parsing-at-rule-invalid.js.
(testInvalidFilterAtRule):
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-at-rule-valid.js: Renamed from LayoutTests/css3/filters/script-tests/custom-filter-parsing-at-rule-valid.js.
(testFilterAtRule):
(testNestedRules):
(checkRule):
* css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt: Removed.
* platform/chromium/css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt: Removed.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142149 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Cookie database isn't loaded into memory in some rare cases
https://bugs.webkit.org/show_bug.cgi?id=109202
PR 286189

Patch by Otto Derek Cheung <otcheung@rim.com> on 2013-02-07
Reviewed by Yong Li.
Internally Reviewed by Konrad Piascik.

If a get/setCookie call is made before the database is loaded, or if there's some
kind of error that causes the loading of the database to fail in the constructor
of CookieManager, the browser will get into a state where it seems like cookie is
permanenty disabled.

Instead of logging the errors and redispatching the setCookie, we should do a force sync
to load the cookie database before continuing.

Since the bug is so difficult to reproduce (I never did so myself), I did the follow test
to make sure the code path is correct:
1) Make sure original implementation is retained - open and loading done in the constructor
2) Removed opening and loading in constructor, the new calls in get/setcookies loaded the db just fine (although with
an initial lag because we are blocking WKT while performing SQLite options).
3) Removed loading in constructor, the new calls loaded the db just fine.

* platform/blackberry/CookieDatabaseBackingStore/CookieDatabaseBackingStore.cpp:
(WebCore::CookieDatabaseBackingStore::openAndLoadDatabaseSynchronously):
(WebCore):
* platform/blackberry/CookieDatabaseBackingStore/CookieDatabaseBackingStore.h:
(CookieDatabaseBackingStore):
* platform/blackberry/CookieManager.cpp:
(WebCore::CookieManager::setCookies):
(WebCore::CookieManager::getCookie):
(WebCore::CookieManager::generateHtmlFragmentForCookies):
(WebCore::CookieManager::getRawCookies):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142150 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WinCairo] Compile fix after r141981
https://bugs.webkit.org/show_bug.cgi?id=109184

Patch by peavo@outlook.com <peavo@outlook.com> on 2013-02-07
Reviewed by Brent Fulgham.

* platform/network/curl/ResourceHandleCurl.cpp:
(WebCore::ResourceHandle::loadResourceSynchronously):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142151 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CSS 2.1 failure: floats-149 fails
https://bugs.webkit.org/show_bug.cgi?id=95772

Reviewed by David Hyatt.

Source/WebCore:

Treat inlines that contain nothing but empty inlines as empty too so that they get a linebox.

Tests: fast/inline/inline-with-empty-inline-children.html
       css2.1/20110323/floats-149.htm

* rendering/InlineIterator.h:
(WebCore::isEmptyInline):
* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::layoutRunsAndFloatsInRange): Now that empty inlines get a linebox any out-of-flow
objects inside an empty inline (on a line that is otherwise empty) won't get positioned while skipping
through leading whitespace.

LayoutTests:

* css2.1/20110323/floats-149-expected.html: Added.
* css2.1/20110323/floats-149.htm: Added.
* fast/inline/inline-with-empty-inline-children-expected.txt: Added.
* fast/inline/inline-with-empty-inline-children.html: Added.
* platform/chromium-win/fast/text/international/bidi-ignored-for-first-child-inline-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142152 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL][WK2] EWK2UnitTestBase.ewk_view_page_contents_get API test is sometimes failing
https://bugs.webkit.org/show_bug.cgi?id=108634

Patch by Christophe Dumez <dchris@gmail.com> on 2013-02-07
Reviewed by Alexey Proskuryakov.

Use more robust data validation in EWK2UnitTestBase.ewk_view_page_contents_get
so that the test passes consistently. The issue was that the header before the
data includes the current date. Depending on the date, the data may start at a
different index in the returned string. Instead of hardcoding the data start
index in the test, we now use String::contains().

* UIProcess/API/efl/tests/test_ewk2_view.cpp:
(PageContentsCallback):
(TEST_F):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142153 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] StringCache::m_stringCache should be HashMap<StringImpl*, Persistent<String>>
https://bugs.webkit.org/show_bug.cgi?id=109123

Reviewed by Adam Barth.

Currently StringCache::m_stringCache is implemented as
HashMap<StringImpl*, v8::String*>. Given that v8::String*
can change when a GC is triggered, it is dangerous to store a raw pointer.
We should use HashMap<StringImpl*, v8::Persistent<v8::String>> instead.

This is a possible fix for an IndexedDB crash (https://bugs.webkit.org/show_bug.cgi?id=105363),
although I'm not sure if this patch fixes the crash. (I couldn't reproduce the crash.)

No tests. This change highly depends on GC behavior and thus it is
difficult to make a reliable test case.

* bindings/v8/V8ValueCache.cpp:
(WebCore::makeExternalString):
* bindings/v8/V8ValueCache.h:
(StringCache):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142154 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Consider replacing return type of Clipboard::types() from ListHashSet<String> to Vector<String>
https://bugs.webkit.org/show_bug.cgi?id=82888

Reviewed by Kentaro Hara.

As part of removing custom bindings of types Array Clipboard::types() needs to return
Vector<String> than ListHashSet<String>

No new tests. Existing test should pass with this change as no behavoural changes.

* bindings/js/JSClipboardCustom.cpp: Replace data type from ListHashSet<> to Vector<>.
(WebCore::JSClipboard::types):
* bindings/v8/custom/V8ClipboardCustom.cpp: Ditto.
(WebCore::V8Clipboard::typesAccessorGetter): Ditto.
* dom/Clipboard.h: Ditto.
* platform/blackberry/ClipboardBlackBerry.cpp: Ditto.
(WebCore::ClipboardBlackBerry::types):
* platform/blackberry/ClipboardBlackBerry.h: Ditto.
* platform/chromium/ChromiumDataObject.cpp: Ditto.
(WebCore::ChromiumDataObject::types):
* platform/chromium/ChromiumDataObject.h: Ditto.
* platform/chromium/ClipboardChromium.cpp: Ditto.
(WebCore::ClipboardChromium::types):
* platform/chromium/ClipboardChromium.h: Ditto.
* platform/efl/ClipboardEfl.cpp: Ditto.
(WebCore::ClipboardEfl::types):
* platform/efl/ClipboardEfl.h: Ditto.
* platform/gtk/ClipboardGtk.cpp: Ditto.
(WebCore::ClipboardGtk::types):
* platform/gtk/ClipboardGtk.h: Ditto.
* platform/mac/ClipboardMac.h: Ditto.
* platform/mac/ClipboardMac.mm: Ditto.
(WebCore::addHTMLClipboardTypesForCocoaType):
(WebCore::ClipboardMac::types):
* platform/qt/ClipboardQt.cpp: Ditto.
(WebCore::ClipboardQt::types):
* platform/qt/ClipboardQt.h: Ditto.
* platform/win/ClipboardWin.cpp: Ditto.
(WebCore::addMimeTypesForFormat):
(WebCore::ClipboardWin::types):
* platform/win/ClipboardWin.h: Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142155 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Do not check enum's casing for WebKit2 C API.
https://bugs.webkit.org/show_bug.cgi?id=109128

Patch by Eunmi Lee <eunmi15.lee@samsung.com> on 2013-02-07
Reviewed by Kenneth Rohde Christiansen.

Add "-readability/enum_casing" for WebKit2 C APIs because we use word
which starts with non-capital letter 'k' for types of enums.

* Scripts/webkitpy/style/checker.py:

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