Flexitem margins should be based on content width, not width
https://bugs.webkit.org/show_bug.cgi?id=96674

Reviewed by Ojan Vafai.

Source/WebCore:

Margins should be based on content width. Also remove some calls to
mainAxisContentExtent() when we can use contentLogicalWidth instead.

Tests: css3/flexbox/percent-margins.html has a new testcase.

* rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::computeMainAxisExtentForChild): Use contentLogicalWidth instead of
passing in the maximum value (only used in the width case).
(WebCore::RenderFlexibleBox::preferredMainAxisContentExtentForChild): Don't pass in mainAxisContentExtent.
(WebCore::RenderFlexibleBox::computeChildMarginValue): Use contentLogicalWidth and simplify the code.
(WebCore::RenderFlexibleBox::computeMainAxisPreferredSizes): Remove unnecessary mainAxisContentExtent() call.
(WebCore::RenderFlexibleBox::adjustChildSizeForMinAndMax): Remove unnecessary flexboxAvailableContentExtent.
(WebCore::RenderFlexibleBox::computeNextFlexLine): Remove unnecessary mainAxisContentExtent() call.
(WebCore::RenderFlexibleBox::resolveFlexibleLengths): Remove unnecessary mainAxisContentExtent() call.
* rendering/RenderFlexibleBox.h: Remove unnecessary params.

LayoutTests:

Add a test case where contentWidth != width.

* css3/flexbox/percent-margins-expected.txt:
* css3/flexbox/percent-margins.html:


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

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

* DEPS:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128487 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Temporarily remove Android Builder (dbg) from garden-o-matic view
https://bugs.webkit.org/show_bug.cgi?id=96678

Reviewed by Dirk Pranke.

* BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/scripts/config.js:
(.):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: Consolidate two-phase connection to avoid race conditions
https://bugs.webkit.org/show_bug.cgi?id=90411

Reviewed by Tony Chang.

Source/WebCore:

Previously, IDB connections were opened by having the front-end (1) call through to
a back-end open() method, eventually receive a success message with a back-end object
handle, and (2) call into the back-end object to register front-end callbacks. This left
the back-end's notion of an open connection in a limbo state between these two calls.
In multi-process ports, a crash of the front-end process could leave the back-end wedged
waiting for this second call (e.g. can't delete until all connections are closed).

Simplify this by having the front-end pass through the callbacks into the back-end
during the initial open() call, which eliminates the limbo state.

No new tests - no functional changes. Chromium port's webkit_unit_tests updated.

* Modules/indexeddb/IDBDatabase.cpp:
(WebCore::IDBDatabase::create):
(WebCore::IDBDatabase::IDBDatabase): Db-callbacks is available at creation time.
(WebCore::IDBDatabase::~IDBDatabase):
* Modules/indexeddb/IDBDatabase.h:
(IDBDatabase):
* Modules/indexeddb/IDBDatabaseBackendImpl.cpp:
(WebCore::IDBDatabaseBackendImpl::PendingOpenCall::create): Need to track db-callbacks as well.
(WebCore::IDBDatabaseBackendImpl::PendingOpenCall::databaseCallbacks):
(WebCore::IDBDatabaseBackendImpl::PendingOpenCall::PendingOpenCall):
(IDBDatabaseBackendImpl::PendingOpenCall):
(WebCore::IDBDatabaseBackendImpl::PendingOpenWithVersionCall::create): Ditto.
(WebCore::IDBDatabaseBackendImpl::PendingOpenWithVersionCall::databaseCallbacks):
(WebCore::IDBDatabaseBackendImpl::PendingOpenWithVersionCall::PendingOpenWithVersionCall):
(IDBDatabaseBackendImpl::PendingOpenWithVersionCall):
(WebCore::IDBDatabaseBackendImpl::IDBDatabaseBackendImpl):
(WebCore::IDBDatabaseBackendImpl::setVersion):
(WebCore::IDBDatabaseBackendImpl::connectionCount): Don't need to count limbo connections any more.
(WebCore::IDBDatabaseBackendImpl::processPendingCalls): Pass through db-callbacks.
(WebCore::IDBDatabaseBackendImpl::openConnection): No more limbo connections (yay!).
(WebCore::IDBDatabaseBackendImpl::runIntVersionChangeTransaction): Pass through db-callbacks.
(WebCore::IDBDatabaseBackendImpl::openConnectionWithVersion): Ditto.
(WebCore::IDBDatabaseBackendImpl::deleteDatabase): Style.
(WebCore::IDBDatabaseBackendImpl::close): Resolve FIXME about connectionCount.
* Modules/indexeddb/IDBDatabaseBackendImpl.h:
(IDBDatabaseBackendImpl):
* Modules/indexeddb/IDBDatabaseBackendInterface.h:
(IDBDatabaseBackendInterface):
* Modules/indexeddb/IDBDatabaseCallbacksImpl.cpp:
(WebCore::IDBDatabaseCallbacksImpl::create):
(WebCore::IDBDatabaseCallbacksImpl::IDBDatabaseCallbacksImpl):
(WebCore::IDBDatabaseCallbacksImpl::connect):
* Modules/indexeddb/IDBDatabaseCallbacksImpl.h:
(IDBDatabaseCallbacksImpl):
* Modules/indexeddb/IDBFactory.cpp:
(WebCore::IDBFactory::open): Mint the db-callbacks here...
* Modules/indexeddb/IDBFactoryBackendImpl.cpp:
(WebCore::IDBFactoryBackendImpl::open): ...passed through to here...
* Modules/indexeddb/IDBFactoryBackendImpl.h:
(IDBFactoryBackendImpl):
* Modules/indexeddb/IDBFactoryBackendInterface.h:
(IDBFactoryBackendInterface):
* Modules/indexeddb/IDBOpenDBRequest.cpp:
(WebCore::IDBOpenDBRequest::create): ...all the way to here...
(WebCore::IDBOpenDBRequest::IDBOpenDBRequest):
(WebCore::IDBOpenDBRequest::onUpgradeNeeded): ...and finally hooked up here.
(WebCore::IDBOpenDBRequest::onSuccess): (or here, if no upgrade needed).
* Modules/indexeddb/IDBOpenDBRequest.h:
(WebCore):
(IDBOpenDBRequest):
* Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::onAbort): Tweak event/notification ordering; the
notifying the database that the transaction is finished may unblock closing,
which fires more events, and the delivery matters. Previously the close would
be blocked by the transaction which gave the desired order.
(WebCore::IDBTransaction::onComplete): Ditto.
* inspector/InspectorIndexedDBAgent.cpp: New hookup logic.
(WebCore):

Source/WebKit/chromium:

API plumbing for simplified single-phase connection opening, and tests updated
to exercise the new APIs.

* public/WebIDBDatabase.h:
(WebIDBDatabase): Just a FIXME to remove the old second-phase hookup API.
* public/WebIDBFactory.h:
(WebKit):
(WebIDBFactory):
(WebKit::WebIDBFactory::open): New overload that takes db-callbacks.
* src/IDBCallbacksProxy.cpp: The db-callbacks plumbing is needed earlier.
(WebKit::IDBCallbacksProxy::onSuccess):
(WebKit::IDBCallbacksProxy::onUpgradeNeeded):
(WebKit):
(WebKit::IDBCallbacksProxy::setDatabaseCallbacks): Needs to hold on to
the db-callbacks and hook it up when the onSuccess callback comes through.
* src/IDBCallbacksProxy.h:
(WebKit):
(IDBCallbacksProxy):
* src/IDBDatabaseBackendProxy.cpp:
* src/IDBDatabaseBackendProxy.h:
(IDBDatabaseBackendProxy):
* src/IDBFactoryBackendProxy.cpp:
(WebKit::IDBFactoryBackendProxy::open):
* src/IDBFactoryBackendProxy.h:
(IDBFactoryBackendProxy):
* src/WebIDBDatabaseImpl.cpp:
(WebKit::WebIDBDatabaseImpl::WebIDBDatabaseImpl):
(WebKit::WebIDBDatabaseImpl::close):
* src/WebIDBDatabaseImpl.h:
(WebIDBDatabaseImpl):
* src/WebIDBFactoryImpl.cpp:
(WebKit::WebIDBFactoryImpl::open):
* src/WebIDBFactoryImpl.h:
(WebIDBFactoryImpl):
* tests/IDBAbortOnCorruptTest.cpp:
(FakeIDBDatabaseCallbacks):
(WebCore::FakeIDBDatabaseCallbacks::create):
(WebCore::FakeIDBDatabaseCallbacks::~FakeIDBDatabaseCallbacks):
(WebCore::FakeIDBDatabaseCallbacks::FakeIDBDatabaseCallbacks):
(WebCore):
(WebCore::TEST): Updated connection sequence.
* tests/IDBDatabaseBackendTest.cpp: Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r128453.
http://trac.webkit.org/changeset/128453
https://bugs.webkit.org/show_bug.cgi?id=96681

Having tests use the same appcache directory leads to timeouts
(Requested by zdobersek on #webkit).

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

Source/WebKit/gtk: 

* WebCoreSupport/DumpRenderTreeSupportGtk.cpp:
(DumpRenderTreeSupportGtk::clearMemoryCache):
* WebCoreSupport/DumpRenderTreeSupportGtk.h:
(DumpRenderTreeSupportGtk):

Tools: 

* DumpRenderTree/gtk/DumpRenderTree.cpp:
(runTest):
* Scripts/webkitpy/layout_tests/port/gtk.py:
(GtkPort.setup_environ_for_server):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128490 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2][WTR] WebKitTestRunner needs testRunner.callShouldCloseOnWebView
https://bugs.webkit.org/show_bug.cgi?id=96366

Patch by Sudarsana Nagineni <sudarsana.nagineni@linux.intel.com> on 2012-09-13
Reviewed by Anders Carlsson.

Source/WebKit2:

Implement testRunner.callShouldCloseOnWebView for WebKitTestRunner
by calling shouldClose() on the FrameLoader.

* WebProcess/InjectedBundle/API/c/WKBundleFrame.cpp:
(WKBundleFrameCallShouldCloseOnWebView):
* WebProcess/InjectedBundle/API/c/WKBundleFrame.h:

Tools:

Implement testRunner.callShouldCloseOnWebView for WebKitTestRunner
by calling shouldClose() on the FrameLoader.

* WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::callShouldCloseOnWebView):
(WTR):
* WebKitTestRunner/InjectedBundle/TestRunner.h:
(TestRunner):

LayoutTests:

Unskip passing test fast/events/onbeforeunload-focused-iframe.html

* platform/wk2/Skipped:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128491 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add new accelerated compositing for overflow scroll setting.
https://bugs.webkit.org/show_bug.cgi?id=95885

Patch by Glenn Hartmann <hartmanng@chromium.org> on 2012-09-13
Reviewed by James Robinson.

wkb.ug/91117 introduces RenderLayer::usesCompositedScrolling(), which
currently returns true if we're overflow scrolling and the element has
been styled with '-webkit-overflow-scrolling: touch'. If this is true,
we get promoted to a composited layer, the associated RenderLayerBacking
gets special scrolling layers and in response to RenderLayer::scrollTo()
we no longer have to invalidate everything to get the scrolled content
in the right spot, thereby avoiding very expensive repaints. It's
unfortunate that we require -webkit-overflow-scrolling: touch, though.
It would be nice if RenderLayer::usesCompositedScrolling() returned true
if the page would continue to behave correctly.  This is what
wkb.ug/94743 is intended to do.  Unfortunately, when we become a
composited layer, we switch from subpixel to grayscale anti-aliasing. We
only want to auto-opt into composited scrolling if we don't mind the
change in anti-aliasing, so we need a flag to enable/disable this
feature.

Source/WebCore:

No new tests -- no change in behaviour.

* page/Settings.h:
(WebCore::Settings::setAcceleratedCompositingForOverflowScrollEnabled):
(WebCore::Settings::acceleratedCompositingForOverflowScrollEnabled):
(Settings):

Source/WebKit/chromium:

* public/WebSettings.h:
* src/WebSettingsImpl.cpp:
(WebKit::WebSettingsImpl::setAcceleratedCompositingForOverflowScrollEnabled):
(WebKit):
* src/WebSettingsImpl.h:
(WebSettingsImpl):

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