[MathML] Center of stretched curly bracket not always vertically centered
https://bugs.webkit.org/show_bug.cgi?id=123715

Reviewed by Brent Fulgham.

Source/WebCore:

* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::fillWithExtensionGlyph): Update an assertion and
handle the case where two glyph pieces abut.
(WebCore::RenderMathMLOperator::paint): Do not offset the center glyph by y().

LayoutTests:

* TestExpectations: Unskip mo-stretch.html. It was skipped originally,
because MathML is changing rapidly, but we need it to test these changes.
* mathml/presentation/mo-stretch.html: Update to show stretching characteristics
of all stretchable glyphs.
* platform/gtk/mathml/presentation/mo-stretch-expected.png:
* platform/gtk/mathml/presentation/mo-stretch-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158931 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix layout test that was actually testing incorrect behaviour.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158932 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make base64url decoding actually work
https://bugs.webkit.org/show_bug.cgi?id=124050

Reviewed by Sam Weinig.

* wtf/text/Base64.cpp: (WTF::base64DecodeInternal): Don't hardcode knowledge about
alphabet, put it into the map.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158933 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Left sidebar on cubic-bezier.com flickers
https://bugs.webkit.org/show_bug.cgi?id=123128

Source/WebCore:

Reviewed by Dean Jackson.

The logic that determined whether position:fixed elements outside the viewport
should be composited was incorrect if the fixed element also had a transform.

layer.calculateLayerBounds() only takes into account painted transforms (since they
affect layer bounds). So we need to compute the bounds relative to the layer
itself, then use localToContainerQuad() to map them to document coordinates,
but only to the RenderView so that we don't hit the page scale transform.

Tests: compositing/layer-creation/fixed-position-transformed-into-view.html
       compositing/layer-creation/fixed-position-transformed-outside-view.html

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

LayoutTests:

Reviewed by Dean Jackson.

Tests with transformed, fixed elements which dump the layer tree to see
which layers get composited.

* compositing/layer-creation/fixed-position-transformed-into-view-expected.txt: Added.
* compositing/layer-creation/fixed-position-transformed-into-view.html: Added.
* compositing/layer-creation/fixed-position-transformed-outside-view-expected.txt: Added.
* compositing/layer-creation/fixed-position-transformed-outside-view.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158934 268f45cc-cd09-0410-ab3c-d52691b4dbfc
InspectorConsoleAgent::didFinishXHRLoading ConsoleMessage should include a column number
https://bugs.webkit.org/show_bug.cgi?id=114316

Patch by László Langó <lango@inf.u-szeged.hu> on 2013-11-08
Reviewed by Timothy Hatcher.

InspectorConsoleAgent::didFinishXHRLoading creates a ConsoleMessage with a line number,
but it should also include a column number. It looks like ultimately the line number comes from
JSXMLHttpRequest::send, it should also be possible to get the column number at the time.
The column number would be needed by the Web Inspector to jump to the proper place in source code
to show where the XHR originated from.

* bindings/js/JSXMLHttpRequestCustom.cpp:
(WebCore::SendFunctor::SendFunctor):
(WebCore::SendFunctor::column):
(WebCore::SendFunctor::operator()):
(WebCore::JSXMLHttpRequest::send):
* inspector/InspectorConsoleAgent.cpp:
(WebCore::InspectorConsoleAgent::didFinishXHRLoading):
* inspector/InspectorConsoleAgent.h:
* inspector/InspectorInstrumentation.cpp:
(WebCore::InspectorInstrumentation::didFinishXHRLoadingImpl):
* inspector/InspectorInstrumentation.h:
(WebCore::InspectorInstrumentation::didFinishXHRLoading):
* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::XMLHttpRequest):
(WebCore::XMLHttpRequest::setLastSendLineAndColumnNumber):
(WebCore::XMLHttpRequest::didFinishLoading):
* xml/XMLHttpRequest.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158935 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add A WKBrowsingContextHandle class
https://bugs.webkit.org/show_bug.cgi?id=124058

Reviewed by Sam Weinig.

The WKBrowsingContextHandle class represents a browsing context and can be sent across process boundaries.

* Shared/API/Cocoa/WKBrowsingContextHandle.h: Added.
* Shared/API/Cocoa/WKBrowsingContextHandle.mm: Added.
(-[WKBrowsingContextHandle _initWithPageID:]):
(-[WKBrowsingContextHandle encodeWithCoder:]):
(-[WKBrowsingContextHandle initWithCoder:]):
(+[WKBrowsingContextHandle supportsSecureCoding]):
* Shared/API/Cocoa/WKBrowsingContextHandleInternal.h: Added.
* UIProcess/API/mac/WKBrowsingContextController.mm:
(-[WKBrowsingContextController handle]):
* UIProcess/API/mac/WKBrowsingContextControllerInternal.h:
* UIProcess/API/mac/WKBrowsingContextControllerPrivate.h:
(NS_ENUM):
* WebKit2.xcodeproj/project.pbxproj:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158936 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move breakpoint (and exception break) functionality into JSC::Debugger.
https://bugs.webkit.org/show_bug.cgi?id=121796.

Reviewed by Geoffrey Garen.

Source/JavaScriptCore: 

- In ScriptDebugServer and JSC::Debugger, SourceID and BreakpointID are
  now numeric tokens.

- JSC::Debugger now tracks user defined breakpoints in a JSC::Breakpoint
  record. Previously, this info is tracked in the ScriptBreakpoint record
  in ScriptDebugServer. The only element of ScriptBreakpoint that is not
  being tracked by JSC::Breakpoint is the ScriptBreakpointAction.
     The ScriptBreakpointAction is still tracked by the ScriptDebugServer
  in a list keyed on the corresponding BreakpointID.
     The ScriptBreakpoint record is now only used as a means of passing
  breakpoint paramaters to the ScriptDebugServer.

- ScriptDebugServer now no longer accesses the JSC::CallFrame* directly.
  It always goes through the DebuggerCallFrame.

* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* debugger/Breakpoint.h: Added.
(JSC::Breakpoint::Breakpoint):
- Breakpoint class to track info for each breakpoint in JSC::Debugger.
* debugger/Debugger.cpp:
(JSC::DebuggerCallFrameScope::DebuggerCallFrameScope):
(JSC::DebuggerCallFrameScope::~DebuggerCallFrameScope):
(JSC::Debugger::Debugger):
(JSC::Debugger::detach):
(JSC::Debugger::updateNeedForOpDebugCallbacks):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::removeBreakpoint):
(JSC::Debugger::hasBreakpoint):
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::setBreakpointsActivated):
(JSC::Debugger::setPauseOnExceptionsState):
(JSC::Debugger::setPauseOnNextStatement):
(JSC::Debugger::breakProgram):
(JSC::Debugger::continueProgram):
(JSC::Debugger::stepIntoStatement):
(JSC::Debugger::stepOverStatement):
(JSC::Debugger::stepOutOfFunction):
(JSC::Debugger::updateCallFrame):
(JSC::Debugger::updateCallFrameAndPauseIfNeeded):
(JSC::Debugger::pauseIfNeeded):
(JSC::Debugger::exception):
(JSC::Debugger::atStatement):
(JSC::Debugger::callEvent):
(JSC::Debugger::returnEvent):
(JSC::Debugger::willExecuteProgram):
(JSC::Debugger::didExecuteProgram):
(JSC::Debugger::didReachBreakpoint):
(JSC::Debugger::currentDebuggerCallFrame):
* debugger/Debugger.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::sourceID):
(JSC::DebuggerCallFrame::sourceIDForCallFrame):
* debugger/DebuggerCallFrame.h:
* debugger/DebuggerPrimitives.h: Added.
- define SourceID, noSourceID, BreakpointID, and noBreakpointID.

Source/WebCore: 

No new tests.

- In ScriptDebugServer and JSC::Debugger, SourceID and BreakpointID are
  now numeric tokens.

- JSC::Debugger now tracks user defined breakpoints in a JSC::Breakpoint
  record. Previously, this info is tracked in the ScriptBreakpoint record
  in ScriptDebugServer. The only element of ScriptBreakpoint that is not
  being tracked by JSC::Breakpoint is the ScriptBreakpointAction.
     The ScriptBreakpointAction is still tracked by the ScriptDebugServer
  in a list keyed on the corresponding BreakpointID.
     The ScriptBreakpoint record is now only used as a means of passing
  breakpoint paramaters to the ScriptDebugServer.

- ScriptDebugServer now no longer accesses the JSC::CallFrame* directly.
  It always goes through the DebuggerCallFrame.

* GNUmakefile.list.am:
* WebCore.vcxproj/WebCore.vcxproj:
* WebCore.vcxproj/WebCore.vcxproj.filters:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/BreakpointID.h: Added.
* bindings/js/ScriptDebugServer.cpp:
(WebCore::ScriptDebugServer::ScriptDebugServer):
(WebCore::ScriptDebugServer::setBreakpoint):
(WebCore::ScriptDebugServer::removeBreakpoint):
(WebCore::ScriptDebugServer::clearBreakpoints):
(WebCore::ScriptDebugServer::dispatchDidPause):
(WebCore::ScriptDebugServer::dispatchDidContinue):
(WebCore::ScriptDebugServer::dispatchDidParseSource):
(WebCore::ScriptDebugServer::notifyDoneProcessingDebuggerEvents):
(WebCore::ScriptDebugServer::needPauseHandling):
(WebCore::ScriptDebugServer::handleBreakpointHit):
(WebCore::ScriptDebugServer::handleExceptionInBreakpointCondition):
(WebCore::ScriptDebugServer::handlePause):
* bindings/js/ScriptDebugServer.h:
* bindings/js/SourceID.h: Added.
* bindings/js/WorkerScriptDebugServer.cpp:
(WebCore::WorkerScriptDebugServer::WorkerScriptDebugServer):
* bindings/js/WorkerScriptDebugServer.h:
* inspector/InspectorDebuggerAgent.cpp:
(WebCore::InspectorDebuggerAgent::InspectorDebuggerAgent):
(WebCore::parseLocation):
(WebCore::InspectorDebuggerAgent::setBreakpoint):
(WebCore::InspectorDebuggerAgent::continueToLocation):
(WebCore::InspectorDebuggerAgent::resolveBreakpoint):
(WebCore::InspectorDebuggerAgent::searchInContent):
(WebCore::InspectorDebuggerAgent::getScriptSource):
(WebCore::InspectorDebuggerAgent::didParseSource):
(WebCore::InspectorDebuggerAgent::didPause):
(WebCore::InspectorDebuggerAgent::clear):
* inspector/InspectorDebuggerAgent.h:
* inspector/ScriptDebugListener.h:

Source/WebKit/mac: 

* WebView/WebScriptDebugger.h:
* WebView/WebScriptDebugger.mm:
(WebScriptDebugger::WebScriptDebugger):
(WebScriptDebugger::handlePause):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158937 268f45cc-cd09-0410-ab3c-d52691b4dbfc
More work on WKBrowsingContextHandle
https://bugs.webkit.org/show_bug.cgi?id=124060

Reviewed by Beth Dakin.

Implement -hash and -isEqual: and add -[WKWebProcessPlugInBrowserContextController handle].

* Shared/API/Cocoa/WKBrowsingContextHandle.mm:
(-[WKBrowsingContextHandle hash]):
(-[WKBrowsingContextHandle isEqual:]):
* Shared/API/Cocoa/WKRemoteObjectCoder.mm:
(decodeInvocation):
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm:
(-[WKWebProcessPlugInBrowserContextController mainFrameDocument]):
(-[WKWebProcessPlugInBrowserContextController selectedRange]):
(-[WKWebProcessPlugInBrowserContextController handle]):
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextControllerInternal.h:
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextControllerPrivate.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158939 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix minor (unobservable) bug in ArrayIterator::next()
https://bugs.webkit.org/show_bug.cgi?id=124061

Reviewed by Beth Dakin.

I noticed this while reading the array iterator code.  Due to how
ArrayIterator::next() and our enumeration behaviour is implemented
this is not actually a code path that can be hit.  But in order to
future proof this it should be correct.

* runtime/JSArrayIterator.cpp:
(JSC::arrayIteratorNext):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove accidentally added files.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add a way to get a WKWebProcessPlugInBrowserContextController from a handle
https://bugs.webkit.org/show_bug.cgi?id=124063

Reviewed by Beth Dakin.

* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm:
(+[WKWebProcessPlugInBrowserContextController lookUpBrowsingContextFromHandle:]):
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextControllerPrivate.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Implement JWK key import for HMAC and AES-CBC
https://bugs.webkit.org/show_bug.cgi?id=124059

Reviewed by Anders Carlsson.

Source/WebCore: 

Tests: crypto/subtle/aes-cbc-import-jwk.html
       crypto/subtle/hmac-import-jwk.html
       crypto/subtle/import-jwk.html

WebCrypto supports multiple key formats - raw, pkcs8, spki, jwk. The design is that
we'll transform these into parsed KeyData subclasses before passing to algorithms.

CryptoKeySerialization is a base class for handling all these formats.

* WebCore.xcodeproj/project.pbxproj: Added new files. Removed CryptoKeyFormat.h.
        
* bindings/js/JSCryptoKeySerializationJWK.h: Added.
* bindings/js/JSCryptoKeySerializationJWK.cpp: Added.
(WebCore::getStringFromJSON): A helper. Note that we can rely on the object being
a nice freshly parsed JSON, no getters or anything.
(WebCore::getBooleanFromJSON): Ditto.
(WebCore::JSCryptoKeySerializationJWK::JSCryptoKeySerializationJWK):
(WebCore::JSCryptoKeySerializationJWK::~JSCryptoKeySerializationJWK):
(WebCore::createHMACParameters): A simple helper.
(WebCore::JSCryptoKeySerializationJWK::reconcileAlgorithm): WebCrypto API is weird,
you can have algorithm parameters both inside a JWK key and passed as importKey()
arguments. They need to agree, whatever that means for specific serialization's
algorithm options (not all necessarily have a 1-1 matching to WebCrypto).
(WebCore::JSCryptoKeySerializationJWK::reconcileUsages): Take an intersection of usages.
(WebCore::JSCryptoKeySerializationJWK::reconcileExtractable): Only extractable if
both JWK and the caller agree.
(WebCore::JSCryptoKeySerializationJWK::keySizeIsValid): Verify validity of JWK key.
(WebCore::JSCryptoKeySerializationJWK::keyData): Return an appropriate KeyData
subclass.

* bindings/js/JSSubtleCryptoCustom.cpp:
(WebCore::ENUM_CLASS): Moved CryptoKeyFormat here.
(WebCore::cryptoKeyFormatFromJSValue): Added a human readable string to an exception.
(WebCore::JSSubtleCrypto::importKey): Support multiple key formats, not just raw.

* crypto/CryptoAlgorithm.cpp: (WebCore::CryptoAlgorithm::importKey):
* crypto/CryptoAlgorithm.h:
Updated signature for importKey to one that makes more sense. Decoding formats all
the way from a binary blob is not something that CryptoAlgorithm subclasses should
do, we now pass a KeyData subclass instead.
Removed exportKey/wrapKey/unwrapKey altogether, because I don't yet know what the
signatures will be.

* crypto/CryptoKeyData.h: Added.
(WebCore::CryptoKeyData::ENUM_CLASS):
(WebCore::CryptoKeyData::CryptoKeyData):
(WebCore::CryptoKeyData::~CryptoKeyData):
(WebCore::CryptoKeyData::format):
A base class for passing key material to algorithms. Currently, only one type is
supported, that being OctetSequence for secret keys. Keys for RSA and EC are more
complicated, and secret/public ones are different too.

* crypto/CryptoKeyFormat.h: Removed. There are too many key format classes
confusingly floating around, and this was only needed in one file for parsing.

* crypto/CryptoKeySerialization.h: Added.
Base class for handling raw/pkcs8/spki/jwk keys.

* crypto/algorithms/CryptoAlgorithmAES_CBC.cpp:
(WebCore::CryptoAlgorithmAES_CBC::importKey):
* crypto/algorithms/CryptoAlgorithmAES_CBC.h:
Updated to use CryptoKeyData.

* crypto/algorithms/CryptoAlgorithmHMAC.cpp:
(WebCore::CryptoAlgorithmHMAC::importKey):
* crypto/algorithms/CryptoAlgorithmHMAC.h:
Updated to use CryptoKeyData.

* crypto/keys/CryptoKeyDataOctetSequence.cpp: Added.
(WebCore::CryptoKeyDataOctetSequence::CryptoKeyDataOctetSequence):
(WebCore::CryptoKeyDataOctetSequence::~CryptoKeyDataOctetSequence):
* crypto/keys/CryptoKeyDataOctetSequence.h: Added.
(WebCore::asCryptoKeyDataOctetSequence):
* crypto/keys/CryptoKeySerializationRaw.cpp: Added.
(WebCore::CryptoKeySerializationRaw::CryptoKeySerializationRaw):
(WebCore::CryptoKeySerializationRaw::~CryptoKeySerializationRaw):
(WebCore::CryptoKeySerializationRaw::reconcileAlgorithm):
(WebCore::CryptoKeySerializationRaw::reconcileUsages):
(WebCore::CryptoKeySerializationRaw::reconcileExtractable):
(WebCore::CryptoKeySerializationRaw::keyData):
* crypto/keys/CryptoKeySerializationRaw.h: Added.
Much code to pass around a Vector<char>.

LayoutTests: 

* crypto/subtle/aes-cbc-import-jwk-expected.txt: Added.
* crypto/subtle/aes-cbc-import-jwk.html: Added.
* crypto/subtle/hmac-import-jwk-expected.txt: Added.
* crypto/subtle/hmac-import-jwk.html: Added.
* crypto/subtle/import-jwk-expected.txt: Added.
* crypto/subtle/import-jwk.html: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Replace __alignof with alignof.

Rubber-stamped by Beth Dakin.

* Platform/CoreIPC/ArgumentCoders.cpp:
(CoreIPC::::encode):
(CoreIPC::decodeStringText):
* Platform/CoreIPC/ArgumentCoders.h:
(CoreIPC::SimpleArgumentCoder::encode):
(CoreIPC::SimpleArgumentCoder::decode):
* Platform/CoreIPC/ArgumentDecoder.h:
(CoreIPC::ArgumentDecoder::bufferIsLargeEnoughToContain):
* WebProcess/WebPage/DecoderAdapter.cpp:
(WebKit::DecoderAdapter::decodeString):
* WebProcess/WebPage/EncoderAdapter.cpp:
(WebKit::EncoderAdapter::encodeString):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158944 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=124064
Some WebCrypto files are not in correct directories

Rubber-stamped by Anders Carlsson.

* WebCore.xcodeproj/project.pbxproj:
* crypto/CryptoAlgorithmAesCbcParams.h: Removed.
* crypto/CryptoAlgorithmAesKeyGenParams.h: Removed.
* crypto/CryptoKeyAES.cpp: Removed.
* crypto/CryptoKeyAES.h: Removed.
* crypto/CryptoKeyMac.cpp: Removed.
* crypto/keys/CryptoKeyAES.cpp: Copied from Source/WebCore/crypto/CryptoKeyAES.cpp.
* crypto/keys/CryptoKeyAES.h: Copied from Source/WebCore/crypto/CryptoKeyAES.h.
* crypto/mac/CryptoKeyMac.cpp: Copied from Source/WebCore/crypto/CryptoKeyMac.cpp.
* crypto/parameters/CryptoAlgorithmAesCbcParams.h: Copied from Source/WebCore/crypto/CryptoAlgorithmAesCbcParams.h.
* crypto/parameters/CryptoAlgorithmAesKeyGenParams.h: Copied from Source/WebCore/crypto/CryptoAlgorithmAesKeyGenParams.h.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158945 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Added myself as a contributor.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Try to fix the 32-bit build.

* Shared/API/Cocoa/WKBrowsingContextHandleInternal.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158947 268f45cc-cd09-0410-ab3c-d52691b4dbfc
More build fixes.

* UIProcess/API/mac/WKConnection.h:
* UIProcess/API/mac/WKConnection.mm:
(didReceiveMessage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158948 268f45cc-cd09-0410-ab3c-d52691b4dbfc
More build fixes.

* UIProcess/API/mac/WKBrowsingContextController.mm:
* UIProcess/API/mac/WKConnection.mm:
(didReceiveMessage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158949 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RenderBlockFlow::nextFloatLogicalBottomBelow should not use ShapeOutsideFloatOffsetMode
https://bugs.webkit.org/show_bug.cgi?id=123931

Reviewed by Sam Weinig.

Rewrite nextFloatLogicalBottomBelow to use the placed floats tree for
the search and to not need ShapeOutsideFloatOffsetMode anymore. This
moves almost all of the logic into FloatingObjects, making a small
reduction in the amount that RenderBlockFlow needs to know about the
implementation of FloatingObjects.

In addition, change ComputeFloatOffsetAdapter to take in LayoutUnits
and roundToInt itself so that all of it's callers can be simplified.

No new tests, no new behavior.

* rendering/FloatingObjects.cpp:
(WebCore::rangesIntersect):
(WebCore::ComputeFloatOffsetAdapter::ComputeFloatOffsetAdapter):
(WebCore::FindNextFloatLogicalBottomAdapter::FindNextFloatLogicalBottomAdapter):
(WebCore::FindNextFloatLogicalBottomAdapter::lowValue):
(WebCore::FindNextFloatLogicalBottomAdapter::highValue):
(WebCore::FindNextFloatLogicalBottomAdapter::nextLogicalBottom):
(WebCore::FindNextFloatLogicalBottomAdapter::nextShapeLogicalBottom):
(WebCore::FindNextFloatLogicalBottomAdapter::collectIfNeeded):
(WebCore::FloatingObjects::findNextFloatLogicalBottomBelow):
(WebCore::FloatingObjects::findNextFloatLogicalBottomBelowForBlock):
(WebCore::FloatingObjects::logicalLeftOffsetForPositioningFloat):
(WebCore::FloatingObjects::logicalRightOffsetForPositioningFloat):
(WebCore::FloatingObjects::logicalLeftOffset):
(WebCore::FloatingObjects::logicalRightOffset):
* rendering/FloatingObjects.h:
* rendering/LineWidth.cpp:
(WebCore::LineWidth::fitBelowFloats):
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::nextFloatLogicalBottomBelow):
(WebCore::RenderBlockFlow::nextFloatLogicalBottomBelowForBlock):
(WebCore::RenderBlockFlow::getClearDelta):
* rendering/RenderBlockFlow.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158954 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove a workaround for a bug in malloc on Symbian
https://bugs.webkit.org/show_bug.cgi?id=124069

Reviewed by Sam Weinig.

* Platform/CoreIPC/ArgumentDecoder.cpp:
(CoreIPC::ArgumentDecoder::~ArgumentDecoder):
(CoreIPC::ArgumentDecoder::initialize):
* Platform/CoreIPC/ArgumentDecoder.h:

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