ASSERT d->m_defersLoading != defers on detik.com and drive.google.com
https://bugs.webkit.org/show_bug.cgi?id=111902

Reviewed by Alexey Proskuryakov.

Source/WebCore:

Test: http/tests/navigation/same-url-iframes-defer-crash.html

* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::setDefersLoading): If multiple DocumentLoaders are
   using loading the same main resource, ensure only one of them can call
   ResourceLoader::setDefersLoading.

LayoutTests:

* http/tests/navigation/same-url-iframes-defer-crash-expected.txt: Added.
* http/tests/navigation/same-url-iframes-defer-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147228 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Mark inspector/debugger/debugger-scripts-reload.html as flaky.

http://webkit.org/b/113589

Unreviewed.

* platform/mac/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147230 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Rollout r146818.

* win/tools/vsprops/FeatureDefines.props:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147231 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Mark fast/workers/worker-close-more.html, worker-document-leak.html and
worker-lifecycle.html as flaky on Windows.

http://webkit.org/b/106415

Unreviewed.

* platform/win/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147232 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: Bind lifetime of in-memory backing stores to IDBFactory backend
https://bugs.webkit.org/show_bug.cgi?id=110820

Reviewed by Tony Chang.

Source/WebCore:

Backing stores are dropped as soon as all connections are closed. That makes sense for
disk-backed stores to free up memory (although there's a performance trade-off...). But
for memory-backed stores, the expected lifetime should match the lifetime of the factory
so that an open/write/close/re-open/read yields the written data.

Test: Chromium's webkit_unit_tests, IDBFactoryBackendTest.MemoryBackingStoreLifetime

* Modules/indexeddb/IDBBackingStore.cpp:
(WebCore::IDBBackingStore::IDBBackingStore): Pass comparator into constructor since it was always
assigned immediately afterwards anyway.
(WebCore::IDBBackingStore::open): Split into three parts - open() which is disk-backed...
(WebCore::IDBBackingStore::openInMemory): ...explit in-memory creation (previously: specified by empty path)
(WebCore::IDBBackingStore::create): ... and the common logic which calls the constructor.
* Modules/indexeddb/IDBBackingStore.h: Headers for the above.
* Modules/indexeddb/IDBFactoryBackendImpl.cpp:
(WebCore::IDBFactoryBackendImpl::openBackingStore): Add in-memory backing stores to dependent set.
* Modules/indexeddb/IDBFactoryBackendImpl.h: Add member to track dependent backing stores.

Source/WebKit/chromium:

* tests/IDBBackingStoreTest.cpp:
(WebCore::IDBBackingStoreTest::SetUp): Use openInMemory rather than empty path.
(WebCore::TEST): Added IDBFactoryBackendTest.MemoryBackingStoreLifetime to verify refs.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147233 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplified bytecode generation by unforking "condition context" codegen
https://bugs.webkit.org/show_bug.cgi?id=113554

Reviewed by Mark Hahnenberg.

Now, a node that establishes a condition context can always ask its child
nodes to generate into that context.

This has a few advantages:

(*) Removes a bunch of code;

(*) Optimizes a few missed cases like "if (!(x < 2))", "if (!!x)", and
"if (!x || !y)";

(*) Paves the way to removing more opcodes.

* bytecode/Opcode.h:
(JSC): Separated out the branching opcodes for clarity.
* bytecompiler/NodesCodegen.cpp:
(JSC::ExpressionNode::emitBytecodeInConditionContext): All expressions
can be emitted in a condition context now -- the default behavior is
to branch based on the expression's value.

(JSC::LogicalNotNode::emitBytecodeInConditionContext):
(JSC::LogicalOpNode::emitBytecodeInConditionContext):
(JSC::ConditionalNode::emitBytecode):
(JSC::IfNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
* parser/Nodes.h:
(JSC::ExpressionNode::isSubtract):
(ExpressionNode):
(LogicalNotNode):
(LogicalOpNode): Removed lots of code for handling expressions
that couldn't generate into a condition context because all expressions
can now.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147234 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Allow multiple searchKeys to be passed to AXUIElementCopyParameterizedAttributeValue
https://bugs.webkit.org/show_bug.cgi?id=112276

Patch by Greg Hughes <ghughes@apple.com> on 2013-03-29
Reviewed by Chris Fleizach.

Source/WebCore:

Added support for accessibility search predicates to accept multiple search keys. The search will return the first item that matches any one of the provided search keys.

* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::isAccessibilityObjectSearchMatchAtIndex):
(WebCore::AccessibilityObject::isAccessibilityObjectSearchMatch):
(WebCore):
* accessibility/AccessibilityObject.h:
(AccessibilitySearchCriteria):
(WebCore::AccessibilitySearchCriteria::AccessibilitySearchCriteria):
(AccessibilityObject):
* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):

Tools:

Added support to test accessibility search predicates with multiple keys.

* DumpRenderTree/AccessibilityUIElement.cpp:
(uiElementForSearchPredicateCallback):
* DumpRenderTree/AccessibilityUIElement.h:
(AccessibilityUIElement):
* DumpRenderTree/atk/AccessibilityUIElementAtk.cpp:
(AccessibilityUIElement::uiElementForSearchPredicate):
* DumpRenderTree/blackberry/AccessibilityUIElementBlackBerry.cpp:
(AccessibilityUIElement::uiElementForSearchPredicate):
* DumpRenderTree/ios/AccessibilityUIElementIOS.mm:
(AccessibilityUIElement::uiElementForSearchPredicate):
* DumpRenderTree/mac/AccessibilityUIElementMac.mm:
(AccessibilityUIElement::uiElementForSearchPredicate):
* DumpRenderTree/win/AccessibilityUIElementWin.cpp:
(AccessibilityUIElement::uiElementForSearchPredicate):
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
(WTR::AccessibilityUIElement::uiElementForSearchPredicate):
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
(AccessibilityUIElement):
* WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:
(WTR::AccessibilityUIElement::uiElementForSearchPredicate):
* WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::uiElementForSearchPredicate):

LayoutTests:

Updated the search predicate test to test passing multiple search keys (link OR heading).

* platform/mac/accessibility/search-predicate-expected.txt:
* platform/mac/accessibility/search-predicate.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147236 268f45cc-cd09-0410-ab3c-d52691b4dbfc
removeViewportConstrainedLayer() should remove the layer from m_viewportConstrainedLayersNeedingUpdate too
https://bugs.webkit.org/show_bug.cgi?id=113596

Reviewed by Tim Horton.

It's possible, with some combination of position:fixed and opacity transitions
in iframes, to end up with a RenderLayer in m_viewportConstrainedLayersNeedingUpdate
that has been removed from m_viewportConstrainedLayers, which leads to later assertions
and/or crashes.

Fix by removing a layer from m_viewportConstrainedLayersNeedingUpdate when we
remove it from m_viewportConstrainedLayers.

I was not able to come up with a testcase that reliably reproduces this.

* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::removeViewportConstrainedLayer):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147238 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Update the version of gyp in the repository
https://bugs.webkit.org/show_bug.cgi?id=113540

Reviewed by Nico Weber.

* gyp: Update gyp to r1605.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147239 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Snapshotted plugins must be able to restart on appropriate mouseup events
https://bugs.webkit.org/show_bug.cgi?id=113577

Reviewed by Tim Horton.

If the page content prevents the default behaviour of a mousedown event, then a snapshotted
plugin would never receive a click event, and thus be unable to restart. We have to also
look for a mouseup that happens with an associated mousedown, and trigger restart. This
won't call any page code - it's just behind the scenes.

* rendering/RenderSnapshottedPlugIn.cpp:
(WebCore::RenderSnapshottedPlugIn::RenderSnapshottedPlugIn): Initialize new member variable.
(WebCore::RenderSnapshottedPlugIn::handleEvent): Track the state of mousedown and up pairs, and restart
    if you see an appropriate mouseup.
* rendering/RenderSnapshottedPlugIn.h: New member variable to track mouse state.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147240 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] IndexedDB: Exceptions thrown inconsistently for non-cloneable values
https://bugs.webkit.org/show_bug.cgi?id=113091

Reviewed by Kentaro Hara.

Source/WebCore:

The exception thrown by SerializedScriptValue into the JS engine is not
observable by ScriptState. (We should fix that, but it appears non-trivial.)
Ask the SerializedScriptValue directly if it failed to clone. If so, don't
set an exception - one was already set so let that be processed normally.

Test: storage/indexeddb/clone-exception.html

* Modules/indexeddb/IDBObjectStore.cpp:
(WebCore::IDBObjectStore::put):

LayoutTests:

* storage/indexeddb/clone-exception-expected.txt: Added.
* storage/indexeddb/clone-exception.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147241 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Marking animation-delay-changed.html and reinserting-svg-into-document.html as flaky.

https://webkit.org/b/113598
https://webkit.org/b/113599

Unreviewed.

* platform/mac/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147243 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: Use WTF::TemporaryChange rather than manually resetting a flag
https://bugs.webkit.org/show_bug.cgi?id=113594

Reviewed by Tony Chang.

Split out from another patch: rather than m_foo = true; ... m_foo = false; use
the handy WTF::TemporaryChange scoped variable change doohickey.

Test: http/tests/inspector/indexeddb/database-structure.html

* Modules/indexeddb/IDBDatabaseBackendImpl.cpp:
(WebCore::IDBDatabaseBackendImpl::close):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
min-width/max-width of min-content/max-content don't work correctly if width is specified
https://bugs.webkit.org/show_bug.cgi?id=106143

Reviewed by Tony Chang.

Source/WebCore:

Test: fast/css-intrinsic-dimensions/intrinsic-sized-blocks.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::computeIntrinsicLogicalWidths):
Expose this so that we don't use the preferred widths when calculating intrinsic width
values since the preferred width will be the regular width value if it is set.
Also, simplified the logic around table cells and scrollbar widths. The old code was
wrong and unnecessarily complicated.

(WebCore::RenderBlock::computePreferredLogicalWidths):
Use the new computeIntrinsicLogicalWidths method.

(WebCore::RenderBlock::computeInlinePreferredLogicalWidths):
(WebCore::RenderBlock::computeBlockPreferredLogicalWidths):
Pass in the min/max values as out params so they can be called from computeIntrinsicLogicalWidths.
Also, make computeBlockPreferredLogicalWidths const.

* rendering/RenderBlock.h:

LayoutTests:

* css3/flexbox/box-sizing.html:
The old result was incorrectly using the preferred width as the min-content width of the flex items.
The new result is correctly resolving the min-content width to 0 and allowing the flex items to shrink.

* fast/css-intrinsic-dimensions/intrinsic-sized-blocks-expected.txt: Added.
* fast/css-intrinsic-dimensions/intrinsic-sized-blocks.html: Added.
* platform/chromium-win/fast/table/overflowHidden-expected.txt:
The new result correctly adds the scrollbar width to the table cell intrinsic width.
The pixel result doesn't need ot be updated because the elements that changed are below
the fold, so they don't show up in the png.

* platform/chromium/TestExpectations:
* platform/efl/TestExpectations:
* platform/gtk/TestExpectations:
* platform/mac/TestExpectations:
* platform/qt/TestExpectations:
Add tests that will need rebaselines.

* scrollbars/custom-scrollbar-table-cell-expected.png:
The new result correctly adds the scrollbar width to the table cell intrinsic width.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147245 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Exclusions] Incorrect margin corner radii formula
https://bugs.webkit.org/show_bug.cgi?id=111186

Reviewed by Dirk Schulze.

Source/WebCore:

Corrected an error in the forumla for the margin ellipse's radii.

Tests: fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-left.html
       fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-right.html

* rendering/ExclusionRectangle.cpp:
(WebCore::FloatRoundedRect::marginBounds):

LayoutTests:

* fast/exclusions/resources/subpixel-utils.js:
(SubPixelLayout): Added an initSubPixelLayout() function so that inline test code doesn't have to wait until the DOMContentLoaded event.
* fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-left-expected.txt: Added.
* fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-left.html: Added.
* fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-right-expected.txt: Added.
* fast/exclusions/shape-outside-floats/shape-outside-floats-ellipse-margin-right.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147249 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Exclusions] shape outside segments not properly calculated for ellipses
https://bugs.webkit.org/show_bug.cgi?id=112587

Patch by Bem Jones-Bey <bjonesbe@adobe.com> on 2013-03-29
Reviewed by Julien Chaffraix.

Source/WebCore:

When converting the line top coordinates from the parent's coordinate
space to the coordinate space of the float, the offset given by the
shape was not being accounted for. This patch accounts for that
offset.

Test: fast/exclusions/shape-outside-floats/shape-outside-floats-non-zero-y.html

* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::logicalLeftOffsetForLine): Fix the coordinate conversion.
(WebCore::RenderBlock::logicalRightOffsetForLine): Ditto.
* rendering/RenderBlockLineLayout.cpp:
(WebCore::LineWidth::shrinkAvailableWidthForNewFloatIfNeeded): Ditto.

LayoutTests:

Check that shapes with a non-zero y value are properly wrapped.

* fast/exclusions/shape-outside-floats/shape-outside-floats-non-zero-y.html: Added.
* fast/exclusions/resources/rounded-rectangle.js:
(generateSimulatedShapeOutsideOnFloat): For simulating, we ignore the
x and y values, since we're not attempting to draw the float's content
in the right place, we just want to simulate the shape's effect.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147250 268f45cc-cd09-0410-ab3c-d52691b4dbfc
"Empty cache..." clears the disk cache from each WebProcess.
<rdar://problem/12456652> and https://bugs.webkit.org/show_bug.cgi?id=113603

Reviewed by Sam Weinig.

* NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::NetworkProcess):
(WebKit::NetworkProcess::terminate): Override ChildProcess::terminate to allow us to finish clearing the cache.
* NetworkProcess/NetworkProcess.h:

* NetworkProcess/NetworkProcess.messages.in: Add the ClearCacheForAllOrigins message.

* NetworkProcess/mac/NetworkProcessMac.mm:
(WebKit::NetworkProcess::clearCacheForAllOrigins): Clear the disk cache.
(WebKit::NetworkProcess::platformTerminate): Wait for the clear to complete.

* UIProcess/WebResourceCacheManagerProxy.cpp:
(WebKit::WebResourceCacheManagerProxy::clearCacheForAllOrigins): Message the network process, also.

* WebProcess/mac/WebProcessMac.mm:
(WebKit::WebProcess::platformClearResourceCaches): Don't clear the disk cache if we use the network process.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147251 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Objective-C API: Remove -[JSManagedValue managedValueWithValue:owner:]
https://bugs.webkit.org/show_bug.cgi?id=113602

Reviewed by Geoffrey Garen.

Since we put the primary way of keeping track of external object graphs (i.e. "managed" references)
in JSVirtualMachine, there is some overlap in the functionality of that interface and JSManagedValue.
Specifically, we no longer need the methods that include an owner, since ownership is now tracked
by JSVirtualMachine. These JSManagedValues will become weak pointers unless they are used
with [JSVirtualMachine addManagedReference:withOwner:], in which case their lifetime is tied to that
of their owner.

* API/JSManagedValue.h:
* API/JSManagedValue.mm:
(-[JSManagedValue init]):
(-[JSManagedValue initWithValue:]):
(JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
* API/JSVirtualMachine.mm:
(getInternalObjcObject):
* API/tests/testapi.mm:
(-[TextXYZ setOnclick:]):
(-[TextXYZ dealloc]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147252 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Should never send events to plugins waiting on asynchronous initialization.
<rdar://problem/13538945> and https://bugs.webkit.org/show_bug.cgi?id=113612

Reviewed by Anders Carlsson.

Sending mouse and keyboard events to a plugin in the middle of asynchronous initialization is silly.

A quick audit of the sendSync() messages in PluginProxy suggests the following 8 can just have an early return:

* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::handleMouseEvent):
(WebKit::PluginProxy::handleWheelEvent):
(WebKit::PluginProxy::handleMouseEnterEvent):
(WebKit::PluginProxy::handleMouseLeaveEvent):
(WebKit::PluginProxy::handleKeyboardEvent):
(WebKit::PluginProxy::handleEditingCommand):
(WebKit::PluginProxy::isEditingCommandEnabled):
(WebKit::PluginProxy::handlesPageScaleFactor):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] IndexedDB: Update terminated worker connection test
https://bugs.webkit.org/show_bug.cgi?id=113608

Reviewed by Tony Chang.

Update layout test only run under Chromium's content_shell that ensures that
worker termination does not result in stuck connections. The test was using
the obsolete setVersion() API.

* storage/indexeddb/pending-version-change-stuck-works-with-terminate-expected.txt:
* storage/indexeddb/pending-version-change-stuck-works-with-terminate.html:
* storage/indexeddb/resources/pending-version-change-stuck.js:
(test.request.onblocked):
(test):


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