Sharing SharedBuffer between WebCore and ImageIO is racy and crash prone
https://bugs.webkit.org/show_bug.cgi?id=135069
<rdar://problem/17470655>

Reviewed by Simon Fraser.

When passing image data to ImageIO for decoding, we pass an NSData subclass that is a wraper
around SharedBuffer. This can be a problem when ImageIO tries to access the data on the CA
thread. End result is data corruption on large image loads and potential crashes. The fix is
to have SharedBuffer create a copy of its data if the data has been passed to ImageIO and
might be accessed concurrently.

Since Vector is not refcounted, we do this by having a new refcounted object in SharedBuffer
that contains the buffer and we pass that in our NSData subclass WebCoreSharedBufferData.
Code that would result in the Vector memory moving e.g. append(), resize(), now checks to
see if the buffer was shared and if so, will create a new copy of the vector. This ensures
that the main thread does not end up invalidating the vector memory that we have passed it
to ImageIO.

No new tests because no functional changes.

* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::makePurgeable):
    Remove early return - createPurgeableMemory() has the correct check now.
* platform/SharedBuffer.cpp:
(WebCore::SharedBuffer::SharedBuffer):
(WebCore::SharedBuffer::adoptVector):
(WebCore::SharedBuffer::createPurgeableBuffer):
    Don't create purgeable buffer if we are sharing the buffer.
(WebCore::SharedBuffer::append):
(WebCore::SharedBuffer::clear):
(WebCore::SharedBuffer::copy):
(WebCore::SharedBuffer::duplicateDataBufferIfNecessary): Added.
    Create a new copy of the data if we have shared the buffer and if appending to it would
    exceed the capacity of the vector resulting in memmove.
(WebCore::SharedBuffer::appendToInternalBuffer): Added.
(WebCore::SharedBuffer::clearInternalBuffer): Added.
(WebCore::SharedBuffer::buffer):
    Create a new copy of the buffer if we have shared it.
(WebCore::SharedBuffer::getSomeData):
* platform/SharedBuffer.h:
* platform/cf/SharedBufferCF.cpp:
(WebCore::SharedBuffer::SharedBuffer):
(WebCore::SharedBuffer::singleDataArrayBuffer):
(WebCore::SharedBuffer::maybeAppendDataArray):
* platform/mac/SharedBufferMac.mm:
    Pass the InternalBuffer object to WebCoreSharedBufferData
(-[WebCoreSharedBufferData dealloc]):
(-[WebCoreSharedBufferData initWithSharedBufferInternalBuffer:]):
(-[WebCoreSharedBufferData length]):
(-[WebCoreSharedBufferData bytes]):
(WebCore::SharedBuffer::createNSData):
    Call createCFData() instead of duplicating code.
(WebCore::SharedBuffer::createCFData):
    If the data is in purgeable memory, make a copy of it since m_buffer was cleared when
    creating the purgeable buffer.
(-[WebCoreSharedBufferData initWithSharedBuffer:]): Deleted.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171526 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSWrapperMap's jsWrapperForObject() needs to defer GC.
<https://webkit.org/b/135258>

Reviewed by Oliver Hunt.

In the process of creating a JS wrapper, jsWrapperForObject() will create
the prototype and constructor of the corresponding ObjC class, as well as
for classes in its inheritance chain.  These prototypes and constructors
are stored in Weak references in the JSObjCClassInfo objects.  During all
the allocation that is being done to create all the prototypes and
constructors as well as the wrapper objects, a GC may occur thereby
collecting one or more of these newly created prototype and constructor
objects.

One example of where this problem can manifest is in wrapperForObject()
which is called from jsWrapperForObject().  In wrapperFoObject(), we do
the following steps:

1. reallocateConstructorAndOrPrototype() which creates the prototype
   object and store it in JSObjCClassInfo's m_prototype which is a Weak
   ref.
2. makeWrapper() to create the wrapper object, which may trigger a GC.
   GC will collect the prototype object and nullify the corresponding
   JSObjCClassInfo's m_prototype Weak ref.
3. call JSObjectSetPrototype() to set the JSObjCClassInfo's m_prototype
   in the newly created wrapper.  This results in the wrapper getting a
   jsNull as a prototype instead of the expected prototype object.

To ensure that the prototype and constructor objects are retained until
they can be referenced properly from the wrapper object,
jsWrapperForObject() should defer GC until it's done with its work.

* API/JSWrapperMap.mm:
(-[JSWrapperMap jsWrapperForObject:]):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171527 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Replay: don't encode/decode primitive types that lack explicit sizes
https://bugs.webkit.org/show_bug.cgi?id=133430

Reviewed by Anders Carlsson.

Source/JavaScriptCore:
Don't support encode/decode of unsigned long, since its size is compiler-dependent.

* replay/EncodedValue.cpp:
(JSC::EncodedValue::convertTo<unsigned long>):
(JSC::unsigned long>::encodeValue): Deleted.
* replay/EncodedValue.h:

Source/WebCore:
Remove uses of unsigned long in encode/decode methods because the type lacks an
explicit size. Move frame index serialization away from using unsigned long.

* replay/ReplayController.cpp:
(WebCore::logDispatchedDOMEvent): Fix the format string.
* replay/SerializationMethods.cpp:
(WebCore::frameIndexFromDocument):
(WebCore::frameIndexFromFrame):
(WebCore::documentFromFrameIndex):
(WebCore::frameFromFrameIndex):
(JSC::EncodingTraits<PluginData>::encodeValue):
(JSC::EncodingTraits<PluginData>::decodeValue):
* replay/SerializationMethods.h:
* replay/WebInputs.json: Remove primitive types without explicit sizes.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171528 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Let WheelEvent wrap a PlatformWheelEvent
https://bugs.webkit.org/show_bug.cgi?id=135244

When WheelEvent is initialized with a PlatformWheelEvent, store that PlatformWheelEvent for future use.

Patch by Wenson Hsieh <wenson_hsieh@apple.com> on 2014-07-24
Reviewed by Beth Dakin.

No new tests because behavior should not have changed.

* dom/WheelEvent.cpp: Added method to access the PlatformWheelEvent.
(WebCore::WheelEvent::WheelEvent):
* dom/WheelEvent.h: Added field to store PlatformWheelEvent, if initialized via PlatformWheelEvent.
(WebCore::WheelEvent::wheelEvent):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171531 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Fixed/Sticky layers can get mispositioned when the layer tree commit change their position or size
https://bugs.webkit.org/show_bug.cgi?id=135227
<rdar://problem/17279500>

Reviewed by Simon Fraser.


Source/WebCore: 
Keep track of the creation/destruction of Fixed and Sticky nodes in the ScrollingTree.

* page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::ScrollingTree):
* page/scrolling/ScrollingTree.h:
(WebCore::ScrollingTree::hasFixedOrSticky):
(WebCore::ScrollingTree::fixedOrStickyNodeAdded):
(WebCore::ScrollingTree::fixedOrStickyNodeRemoved):
* page/scrolling/mac/ScrollingTreeFixedNode.mm:
(WebCore::ScrollingTreeFixedNode::ScrollingTreeFixedNode):
(WebCore::ScrollingTreeFixedNode::~ScrollingTreeFixedNode):
* page/scrolling/mac/ScrollingTreeStickyNode.mm:
(WebCore::ScrollingTreeStickyNode::ScrollingTreeStickyNode):
(WebCore::ScrollingTreeStickyNode::~ScrollingTreeStickyNode):

Source/WebKit2: 
In some cases, a fixed or sticky positioned layer would end up at its position corresponding to the WebProcess
instead of sticking the to real viewport in the UIProcess.

The sequence of event is:
1) A layer becomes fixed in some ScrollingTree transaction.
2) Later, some change in the WebProcess causes a LayerTree update for that exact same layer, but no corresponding
   ScrollingTree update is made.
3) In the UIProcess, the position of the fixed layer is changed due to the LayerTree update.
   But! There is no ScrollingTree change, updateScrollingTree() never sets fixedOrStickyLayerChanged to true,
   and the position is not corrected.
-> The layer is now at the wrong position until the next VisibleContentRectUpdate.

Ideally, we should have fixedOrStickyLayerChanged track if either the position or size of a fixed layer changed
in the layer tree. This is tricky since the layer tree does not keep track of the fixed nodes of the scrolling tree.

Since this complexity seems risky at this point, I went for something simpler but with more overhead:
any time the scrolling tree contains either a fixed or sticky layer, viewportChangedViaDelegatedScrolling()
is called to "fix" the position.

* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::updateScrollingTree):
(WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers):
* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::hasFixedOrSticky):
* UIProcess/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers):
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171532 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: <rdar://problem/17766348> [Cocoa] WebCore::ProtectionSpace doesn’t preserve all NSURLProtectionSpace properties, such as the distinguishedNames array
https://bugs.webkit.org/show_bug.cgi?id=135229

Reviewed by Alexey Proskuryakov.

* CMakeLists.txt: Updated for rename of a source file.

* WebCore.exp.in: Updated.

* WebCore.vcxproj/WebCore.vcxproj: Updated for rename of source files, added
ProtectionSpaceCFNet.{cpp,h}.
* WebCore.vcxproj/WebCore.vcxproj.filters: Ditto.

* WebCore.xcodeproj/project.pbxproj: Updated for rename of source files, added
ProtectionSpaceCococa.{h.mm}.

* platform/network/ProtectionSpace.cpp: Renamed to ProtectionSpaceBase.cpp.
* platform/network/ProtectionSpace.h: This file was renamed to ProtectionSpaceBase.h, and
in its place added a generic ProtectionSpace class that just derives from
ProtectionSpaceBase. For Cocoa and CFNetwork, ProtectionSpace{Cocoa,CFNet}.h is included
instead of the generic class.

* platform/network/ProtectionSpaceBase.cpp: Renamed ProtectionSpace.cpp to this.
(WebCore::ProtectionSpaceBase::ProtectionSpaceBase): Updated for rename.
(WebCore::ProtectionSpaceBase::host): Ditto.
(WebCore::ProtectionSpaceBase::port): Ditto.
(WebCore::ProtectionSpaceBase::serverType): Ditto.
(WebCore::ProtectionSpaceBase::isProxy): Ditto.
(WebCore::ProtectionSpaceBase::realm): Ditto.
(WebCore::ProtectionSpaceBase::authenticationScheme): Ditto.
(WebCore::ProtectionSpaceBase::receivesCredentialSecurely): Removed CFNetwork-specific part,
which is now implemented in ProtectionSpaceCFNet.cpp.
(WebCore::ProtectionSpaceBase::compare): Replaced operator== with this, and made it call
ProtectionSpace::platformCompare at the end if needed.

* platform/network/ProtectionSpaceBase.h: Renamed ProtectionSpace.h to this.
(WebCore::ProtectionSpaceBase::encodingRequiresPlatformData): Added with a default
implementation that returns false, for ProtectionSpace implementations to override.
(WebCore::ProtectionSpaceBase::platformCompare): Added with a default implementation that
returns true, for ProtectionSpace implementations to override.
(WebCore::operator==): Changed to call compare.

* platform/network/cf/AuthenticationCF.cpp:
(WebCore::AuthenticationChallenge::AuthenticationChallenge): Changed to use the
ProtectionSpace constructor that takes a CFURLProtectionSpaceRef.
(WebCore::createCF): Changed to use ProtectionSpace::cfSpace.

* platform/network/cf/AuthenticationCF.h: Guarded a couple of functiosn that aren’t used in
Cocoa with #if PLATFORM(WIN).

* platform/network/cf/CredentialStorageCFNet.cpp:
(WebCore::CredentialStorage::getFromPersistentStorage): Changed to use
ProtectionSpace::cfSpace.
(WebCore::CredentialStorage::saveToPersistentStorage): Ditto.

* platform/network/cf/ProtectionSpaceCFNet.cpp: Added.
(WebCore::ProtectionSpaceBase::receivesCredentialSecurely): Override with the
CFNetwork-specific test that was previously in ProtectionSpace.cpp.

* platform/network/cf/ProtectionSpaceCFNet.h: Copied from Source/WebCore/platform/network/ProtectionSpace.h.
Declare ProtectionSpace and override receivesCredentialSecurely.

* platform/network/mac/AuthenticationMac.h: Deleted the ProtectionSpace core() and mac().
* platform/network/mac/AuthenticationMac.mm:
(WebCore::AuthenticationChallenge::AuthenticationChallenge): Changed to use the
ProtectionSpace constructor that takes an NSURLProtectionSpace.
(WebCore::mac): Changed to use ProtectionSpace::nsSpace.

* platform/network/mac/CredentialStorageMac.mm:
(WebCore::CredentialStorage::getFromPersistentStorage): Ditto.

* platform/network/mac/ResourceHandleMac.mm:
(WebCore::ResourceHandle::receivedCredential): Changed to use the ProtectionSpace
constructor that takes an NSURLProtectionSpace.

* platform/network/mac/WebCoreResourceHandleAsDelegate.mm:
(-[WebCoreResourceHandleAsDelegate connection:canAuthenticateAgainstProtectionSpace:]):
Ditto.

* platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm:
(-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]):
Ditto.

Source/WebKit/mac: WebKit part of <rdar://problem/17766348> [Cocoa] WebCore::ProtectionSpace doesn’t preserve all NSURLProtectionSpace properties, such as the distinguishedNames array
https://bugs.webkit.org/show_bug.cgi?id=135229

Reviewed by Alexey Proskuryakov.

* Misc/WebDownload.mm:
(-[WebDownloadInternal download:didReceiveAuthenticationChallenge:]): Chanegd to use the
ProtectionSpace constructor that takes an NSURLProtectionSpace.

* Plugins/WebBaseNetscapePluginView.mm:
(WebKit::getAuthenticationInfo): Ditto.

* WebCoreSupport/WebFrameLoaderClient.mm:
(WebFrameLoaderClient::canAuthenticateAgainstProtectionSpace): Changed to use
ProtectionSpace::nsSpace.

Source/WebKit2: WebKit2 part of <rdar://problem/17766348> [Cocoa] WebCore::ProtectionSpace doesn’t preserve all NSURLProtectionSpace properties, such as the distinguishedNames array
https://bugs.webkit.org/show_bug.cgi?id=135229

Reviewed by Alexey Proskuryakov.

* Shared/Cocoa/WKNSURLProtectionSpace.mm: Changed to use ProtectionSpace::nsSpace.

* Shared/WebCoreArgumentCoders.cpp:
(IPC::ArgumentCoder<ProtectionSpace>::encode): If encoding the space requires encoding the
platform data, do that.
(IPC::ArgumentCoder<ProtectionSpace>::decode): If platform data was encoded, decode it.
* Shared/WebCoreArgumentCoders.h:

* Shared/mac/WebCoreArgumentCodersMac.mm:
(IPC::ArgumentCoder<ProtectionSpace>::encodePlatformData): Archive the NSURLProtectionSpace.
(IPC::ArgumentCoder<ProtectionSpace>::decodePlatformData): Unarchive it.

* Shared/soup/WebCoreArgumentCodersSoup.cpp:
(IPC::ArgumentCoder<ProtectionSpace>::encodePlatformData): Added.
(IPC::ArgumentCoder<ProtectionSpace>::decodePlatformData): Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Creating a JSGlobalObject with a custom JSClassRef results in a JSProxy with the wrong prototype
https://bugs.webkit.org/show_bug.cgi?id=135250

Reviewed by Geoffrey Garen.

JSGlobalObject::resetPrototype (which is called from JSGlobalContextCreateInGroup) doesn't change its 
JSProxy's prototype as well. This results in a JSProxy where no properties in the original prototype 
chain (as created from the JSClassRef hierarchy) are accessible. Changing resetPrototype to also change
the JSProxy's prototype fixes the issue.

* API/JSValueRef.cpp:
(JSValueIsObjectOfClass): Also fixed a bug where a JSProxy for a JSGlobalObject with a custom JSClassRef
would claim it wasn't of the specified class, even if the target was of the specified class.
* API/tests/CustomGlobalObjectClassTest.c: Added.
(jsDoSomething):
(customGlobalObjectClassTest):
* API/tests/CustomGlobalObjectClassTest.h: Added.
* API/tests/testapi.c:
(assertTrue):
(main):
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::resetPrototype):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171543 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Attempted Windows build fix.

* platform/network/cf/AuthenticationCF.cpp:
(WebCore::AuthenticationChallenge::AuthenticationChallenge):
* platform/network/cf/CredentialStorageCFNet.cpp:
(WebCore::CredentialStorage::getFromPersistentStorage):
* platform/network/cf/ProtectionSpaceCFNet.cpp:
(WebCore::ProtectionSpace::receivesCredentialSecurely):
(WebCore::ProtectionSpaceBase::receivesCredentialSecurely): Deleted.



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