Call instruction for the baseline JIT stores origin info in wrong callframe
https://bugs.webkit.org/show_bug.cgi?id=84645

Reviewed by Gavin Barraclough.

Source/JavaScriptCore:

The baseline JIT was updating the wrong callframe when making a call.  If the
call failed during dispatch (unable to perform codegen, calling a non-object)
we would attempt to use this information, but it would be completely wrong.

* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):

LayoutTests:

Directly force LLInt, Baseline, and DFG JITs to handle the path where
a call fails during dispatch.

* fast/js/script-tests/stack-trace.js:
(callNonCallable):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114959 268f45cc-cd09-0410-ab3c-d52691b4dbfc
run-perf-tests fail intermittently with an exception
https://bugs.webkit.org/show_bug.cgi?id=83532

Reviewed by Ryosuke Niwa.

This bulletproofs port.get_option('child_processes')
against the case where the option wasn't set.

* Scripts/webkitpy/layout_tests/port/mac.py:
(MacPort._get_crash_log):
* Scripts/webkitpy/layout_tests/port/mac_unittest.py:
(test_get_crash_log):
(test_get_crash_log.fake_time_cb):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114960 268f45cc-cd09-0410-ab3c-d52691b4dbfc
framebuffer binding should not be changed after canvas resize or compositing
https://bugs.webkit.org/show_bug.cgi?id=84609

Reviewed by Kenneth Russell.

Source/WebCore: 

Test: fast/canvas/webgl/framebuffer-bindings-unaffected-on-resize.html

* html/canvas/WebGLRenderingContext.cpp: set framebuffer binding to DrawingBuffer.
(WebCore):
(WebCore::WebGLRenderingContext::bindFramebuffer):
(WebCore::WebGLRenderingContext::deleteFramebuffer):
(WebCore::WebGLRenderingContext::loseContextImpl):
* platform/graphics/cairo/DrawingBufferCairo.cpp: initialize m_framebufferBinding.
(WebCore::DrawingBuffer::DrawingBuffer):
* platform/graphics/chromium/DrawingBufferChromium.cpp: Ditto.
(WebCore::DrawingBuffer::DrawingBuffer):
* platform/graphics/chromium/WebGLLayerChromium.cpp: Recover framebuffer binding after update().
(WebCore::WebGLLayerChromium::update):
* platform/graphics/gpu/DrawingBuffer.cpp: Add a function to restore framebuffer binding.
(WebCore::DrawingBuffer::restoreFramebufferBinding):
(WebCore):
* platform/graphics/gpu/DrawingBuffer.h: Ditto.
(WebCore::DrawingBuffer::setTexture2DBinding):
(DrawingBuffer):
(WebCore::DrawingBuffer::setFramebufferBinding):
* platform/graphics/gpu/mac/DrawingBufferMac.mm: initialize m_framebufferBinding.
(WebCore::DrawingBuffer::DrawingBuffer):
* platform/graphics/gpu/qt/DrawingBufferQt.cpp: initialize m_framebufferBinding.
(WebCore::DrawingBuffer::DrawingBuffer):

LayoutTests: 

* fast/canvas/webgl/framebuffer-bindings-unaffected-on-resize-expected.txt: Added.
* fast/canvas/webgl/framebuffer-bindings-unaffected-on-resize.html: Added.
* fast/canvas/webgl/resources/webgl-test-utils.js: Sync with khronos side (partial)
(WebGLTestUtils.):
(WebGLTestUtils):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114961 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Cut dependency on RenderLayer::scrollRectToVisible outside rendering
https://bugs.webkit.org/show_bug.cgi?id=84607

Reviewed by Simon Fraser.

Source/WebCore:

Layering fix only, there should be no change behavior.

Because we don't have an accessor on RenderObject, a lot of the code needs
to know about RenderLayer. This is not necessary and exposes RenderLayer to
objects that shouldn't know about it.

This patch adds a RenderObject::scrollRectToVisible with the ad-hoc explanation
as to why it isn't on RenderBox (scrolling is a RenderBox concept).

* WebCore.exp.in:
* WebCore.order:
Updated to expose the new method.

* dom/Element.cpp:
(WebCore::Element::scrollIntoView):
(WebCore::Element::scrollIntoViewIfNeeded):
(WebCore::Element::updateFocusAppearance):
* editing/Editor.cpp:
(WebCore::Editor::findStringAndScrollToVisible):
* editing/FrameSelection.cpp:
(WebCore::FrameSelection::revealSelection):
* page/FrameView.cpp:
(WebCore::FrameView::scrollToAnchor):
Updated those call sites to use the new function.

* rendering/RenderLayer.h:
Removed ScrollBehavior.h #include and default argument values
as we are always called through RenderObject now.

* rendering/RenderObject.cpp:
(WebCore::RenderObject::scrollRectToVisible):
* rendering/RenderObject.h:
Added a new function that just forwards to the enclosing layer
if any. We return whether we actually tried to scroll to match
some call sites expectations.

Source/WebKit/mac:

* WebView/WebFrame.mm:
(-[WebFrame _scrollDOMRangeToVisible:]):
Updated to use RenderObject::scrollRectToVisible and not depend on RenderLayer.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114962 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Visualize accelerated compositor rects.
https://bugs.webkit.org/show_bug.cgi?id=79400

Reviewed by Adrienne Walker.

No tests, all the code added is only debugging code.

This patch adds support for visualizing three different types of
rects on the chromium heads-up display:
1. updateRects that indicate what was painted/uploaded to a resource
2. propertyChangedRects that indicate layers that has property changes
3. surfaceDamageRects that are the accumulation of updateRects and
   propertyChangedRects, indicating what pixels on the screen have
   actually changed.  (Surface damage also accounts for newly exposed
   areas but that is not explicitly visualized.)

In addition to adding support for visualizing this, the
CCHeadsUpDisplay was significantly refactored, separating the FPS
Counter functionality into a different class, so that the heads-up
display is all about visualizing annotations, and those
annotations (frame rate, debug rects) are logged separately.

* WebCore.gypi:
* platform/graphics/chromium/cc/CCDebugRectHistory.cpp: Added.
(WebCore):
(WebCore::CCDebugRectHistory::CCDebugRectHistory):
(WebCore::CCDebugRectHistory::enabled):
(WebCore::CCDebugRectHistory::saveDebugRectsForCurrentFrame):
(WebCore::CCDebugRectHistory::savePaintRects):
(WebCore::CCDebugRectHistory::savePropertyChangedRects):
(WebCore::CCDebugRectHistory::saveSurfaceDamageRects):
* platform/graphics/chromium/cc/CCDebugRectHistory.h: Added.
(WebCore):
(WebCore::CCDebugRect::CCDebugRect):
(CCDebugRect):
(CCDebugRectHistory):
(WebCore::CCDebugRectHistory::create):
(WebCore::CCDebugRectHistory::debugRects):
* platform/graphics/chromium/cc/CCFrameRateCounter.cpp: Added.
(WebCore):
(WebCore::safeMod):
(WebCore::CCFrameRateCounter::frameIndex):
(WebCore::CCFrameRateCounter::CCFrameRateCounter):
(WebCore::CCFrameRateCounter::markBeginningOfFrame):
(WebCore::CCFrameRateCounter::markEndOfFrame):
(WebCore::CCFrameRateCounter::isBadFrameInterval):
(WebCore::CCFrameRateCounter::isBadFrame):
(WebCore::CCFrameRateCounter::getAverageFPSAndStandardDeviation):
(WebCore::CCFrameRateCounter::timeStampOfRecentFrame):
* platform/graphics/chromium/cc/CCFrameRateCounter.h: Added.
(WebCore):
(CCFrameRateCounter):
(WebCore::CCFrameRateCounter::create):
(WebCore::CCFrameRateCounter::currentFrameNumber):
(WebCore::CCFrameRateCounter::timeStampHistorySize):
* platform/graphics/chromium/cc/CCHeadsUpDisplay.cpp:
(WebCore):
(WebCore::CCHeadsUpDisplay::enabled):
(WebCore::CCHeadsUpDisplay::showDebugRects):
(WebCore::CCHeadsUpDisplay::draw):
(WebCore::CCHeadsUpDisplay::drawHudContents):
(WebCore::CCHeadsUpDisplay::drawFPSCounter):
(WebCore::CCHeadsUpDisplay::drawFPSCounterText):
(WebCore::CCHeadsUpDisplay::drawDebugRects):
* platform/graphics/chromium/cc/CCHeadsUpDisplay.h:
(WebCore):
(CCHeadsUpDisplay):
(WebCore::CCHeadsUpDisplay::CCHeadsUpDisplay):
* platform/graphics/chromium/cc/CCLayerTreeHost.h:
(WebCore::CCSettings::CCSettings):
(CCSettings):
* platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:
(WebCore::CCLayerTreeHostImpl::CCLayerTreeHostImpl):
(WebCore::CCLayerTreeHostImpl::calculateRenderPasses):
(WebCore::CCLayerTreeHostImpl::drawLayers):
(WebCore::CCLayerTreeHostImpl::swapBuffers):
* platform/graphics/chromium/cc/CCLayerTreeHostImpl.h:
(WebCore):
(WebCore::CCLayerTreeHostImpl::fpsCounter):
(WebCore::CCLayerTreeHostImpl::debugRectHistory):
(CCLayerTreeHostImpl):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114963 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Split LayoutTests/ChangeLog.

* ChangeLog-2012-04-23: Copied from LayoutTests/ChangeLog.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114964 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: REGRESSION (r100311): YummySoup app crashes when trying to print
https://bugs.webkit.org/show_bug.cgi?id=83918

Reviewed by Alexey Proskuryakov.

Test: http/tests/xmlhttprequest/cancel-during-failure-crash.html

* loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didFinishLoading):
(WebCore::SubresourceLoader::didFail):
(WebCore::SubresourceLoader::willCancel): Now that we might enter the function if we're already Finishing,
    some cleanup needs to be done in the Initialized state only.
(WebCore::SubresourceLoader::releaseResources): Move requesting counting decrement and laodDone() to
    the finishing functions.

LayoutTests: Test for https://bugs.webkit.org/show_bug.cgi?id=83918.

Reviewed by Alexey Proskuryakov.

* http/tests/cache/cancel-during-failure-crash-expected.txt: Added.
* http/tests/cache/cancel-during-failure-crash.html: Added.
* platform/chromium-mac/security/block-test-expected.txt:
* platform/chromium-win/security/block-test-expected.txt:
* platform/gtk/security/block-test-expected.txt:
* platform/mac/security/block-test-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114965 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, test expectations update.

* platform/chromium/test_expectations.txt



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114967 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DFG OSR exit should ensure that all variables have been initialized
https://bugs.webkit.org/show_bug.cgi?id=84653
<rdar://problem/11258183>

Source/JavaScriptCore: 

Reviewed by Gavin Barraclough.
        
Initialize all uncaptured dead variables to undefined on OSR exit.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::ValueSource::dump):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
* dfg/DFGSpeculativeJIT.h:

LayoutTests: 

Reviewed by Gavin Barraclough.

* fast/js/dfg-dead-variable-on-exit-expected.txt: Added.
* fast/js/dfg-dead-variable-on-exit.html: Added.
* fast/js/script-tests/dfg-dead-variable-on-exit.js: Added.
(foo):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114969 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move AudioDestinationChromium FIFO class to its own class.
https://bugs.webkit.org/show_bug.cgi?id=84058

Patch by Raymond Toy <rtoy@google.com> on 2012-04-23
Reviewed by Chris Rogers.

Source/WebCore:

Current tests cover the changes.

* WebCore.gypi: Update with new files.
* platform/audio/AudioPullFIFO.cpp: Copied from Source/WebKit/chromium/src/AudioDestinationChromium.cpp.
(WebCore): Renamed old class the AudioPullFIFO.
(WebCore::AudioPullFIFO::AudioPullFIFO):
(WebCore::AudioPullFIFO::consume):
(WebCore::AudioPullFIFO::findWrapLengths):
(WebCore::AudioPullFIFO::fillBuffer):
* platform/audio/AudioPullFIFO.h: Added.
(WebCore):
(AudioPullFIFO):
(WebCore::AudioPullFIFO::updateIndex):

Source/WebKit/chromium:

Remove private FIFO class and use new AudioPullFIFO class.
* src/AudioDestinationChromium.cpp:
(WebCore::AudioDestinationChromium::AudioDestinationChromium):
* src/AudioDestinationChromium.h:
(AudioDestinationChromium):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114970 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move the content of LocalizedCalendarICU.cpp and LocalizedDateICU.cpp to ICULocale.cpp.
https://bugs.webkit.org/show_bug.cgi?id=84568

Reviewed by Hajime Morita.

Move it to ICULocal.cpp because we want to share UDateFormat
object in LocalizedDate functions and LocalizedCalendar functions,
and it becomes easier to cache the UDateFormat object, and making
unit tests for these functions easier.

No new tests because of no bahevior changes.

* platform/text/ICULocale.cpp:
(WebCore::ICULocale::ICULocale): Initialize new members.
(WebCore::ICULocale::~ICULocale): Delete m_shortDateFormat.
(WebCore::ICULocale::initializeShortDateFormat):
Moved from creteShortDateFormatter of LocalizedDateICU.cpp.
(WebCore::ICULocale::parseLocalizedDate):
Moved from LocalizedDate.cpp, use m_shortDateFormat.
(WebCore::ICULocale::formatLocalizedDate): ditto.
(WebCore::ICULocale::createLabelVector):
Moved from LocalizedCalendarICU.cpp, use m_shortDateFormat.
(WebCore::createFallbackMonthLabels): Moved from LocalizedCalendarICU.cpp.
(WebCore::createFallbackWeekDayShortLabels): ditto.
(WebCore::ICULocale::initializeCalendar):
lazy initialization of m_monthLabels, m_weekDayShortLabels, and m_firstDayOfWeek.
(WebCore::ICULocale::monthLabels):
(WebCore::ICULocale::weekDayShortLabels):
(WebCore::ICULocale::firstDayOfWeek):
* platform/text/ICULocale.h:
(ICULocale): Add declarations.
* platform/text/LocalizedCalendarICU.cpp:
(WebCore::monthLabels): Use ICULocale::currentLocale().
(WebCore::weekDayShortLabels): ditto.
(WebCore::firstDayOfWeek): ditto.
* platform/text/LocalizedDateICU.cpp:
(WebCore::parseLocalizedDate): ditto.
(WebCore::formatLocalizedDate): ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114971 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] Pass Isolate to toV8() (Part6)
https://bugs.webkit.org/show_bug.cgi?id=84273

Reviewed by Nate Chapin.

The objective is to pass Isolate to all toV8()s.
Since there are a lot of toV8()s, I'll make the change
step by step. This patch passes Isolate to toV8() in
several custom bindings.

No tests. No change in behavior.

* bindings/v8/custom/V8HTMLAllCollectionCustom.cpp:
(WebCore::getNamedItems):
(WebCore::getItem):
(WebCore::V8HTMLAllCollection::namedPropertyGetter):
(WebCore::V8HTMLAllCollection::itemCallback):
(WebCore::V8HTMLAllCollection::namedItemCallback):
(WebCore::V8HTMLAllCollection::callAsFunctionCallback):
* bindings/v8/custom/V8HTMLCollectionCustom.cpp:
(WebCore::getNamedItems):
(WebCore::V8HTMLCollection::namedPropertyGetter):
(WebCore::V8HTMLCollection::namedItemCallback):
(WebCore::toV8):
* bindings/v8/custom/V8SVGPathSegCustom.cpp:
(WebCore::toV8):
* bindings/v8/custom/V8StyleSheetCustom.cpp:
(WebCore::toV8):
* bindings/v8/custom/V8StyleSheetListCustom.cpp:
(WebCore::V8StyleSheetList::namedPropertyGetter):
* bindings/v8/custom/V8TrackEventCustom.cpp:
(WebCore::V8TrackEvent::trackAccessorGetter):
* bindings/v8/custom/V8WebGLRenderingContextCustom.cpp:
(WebCore::toV8Object):
(WebCore::getObjectParameter):
(WebCore::V8WebGLRenderingContext::getAttachedShadersCallback):
(WebCore::V8WebGLRenderingContext::getExtensionCallback):
(WebCore::V8WebGLRenderingContext::getFramebufferAttachmentParameterCallback):
(WebCore::V8WebGLRenderingContext::getParameterCallback):
(WebCore::V8WebGLRenderingContext::getProgramParameterCallback):
(WebCore::V8WebGLRenderingContext::getShaderParameterCallback):
(WebCore::V8WebGLRenderingContext::getUniformCallback):
* bindings/v8/custom/V8XMLHttpRequestCustom.cpp:
(WebCore::V8XMLHttpRequest::responseAccessorGetter):
* bindings/v8/custom/V8XSLTProcessorCustom.cpp:
(WebCore::V8XSLTProcessor::transformToFragmentCallback):
(WebCore::V8XSLTProcessor::transformToDocumentCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114972 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RenderDetailsMarker should draw the triangle inside the content box
https://bugs.webkit.org/show_bug.cgi?id=84557

Reviewed by Hajime Morita.

Source/WebCore:

RenderDetailsMarker didn't support cases in which a marker has
borders and/or padings, or non-square size.

Test: fast/html/details-marker-style.html

* rendering/RenderDetailsMarker.cpp:
(WebCore::RenderDetailsMarker::getPath):
Scale by contentWidth() and contentHeight().
(WebCore::RenderDetailsMarker::paint):
Move the trianle origin by the ammount of left/top borders and paddings.

LayoutTests:

* fast/html/details-marker-style.html: Added.
* platform/mac-snowleopard/fast/html/details-marker-style-expected.png: Added.
* platform/mac-snowleopard/fast/html/details-marker-style-expected.txt: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114973 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Return value from executed script in Chromium.
https://bugs.webkit.org/show_bug.cgi?id=79851

Patch by Eriq Augustine <eaugusti@chromium.org> on 2012-04-23
Reviewed by Adam Barth.

Source/WebCore:

Providing a varaiant of evaluateScriptInIsolatedWorld that
returns the value of the evaluated script.

Test: platform/chromium/http/tests/misc/execute-and-return-value.html

* bindings/v8/ScriptController.cpp:
(WebCore::ScriptController::evaluateInIsolatedWorld):
* bindings/v8/ScriptController.h:
(ScriptController):
* bindings/v8/V8Proxy.cpp:
(WebCore::V8Proxy::evaluateInIsolatedWorld):
* bindings/v8/V8Proxy.h:
(V8Proxy):

Source/WebKit/chromium:

Providing a variant of evaluateScriptInIsolatedWorld that
returns the value of the evaluated script.

* public/WebFrame.h:
(WebFrame):
* src/WebFrameImpl.cpp:
(WebKit::WebFrameImpl::executeScriptInIsolatedWorldAndReturnValues):
(WebKit):
* src/WebFrameImpl.h:
(WebKit):
(WebFrameImpl):

Tools:

Adding a function to LayoutTestController that evaluates a script in
an isolated wold an returns the result of the evaluation.

* DumpRenderTree/LayoutTestController.cpp:
(evaluateScriptInIsolatedWorldAndReturnValue):
(LayoutTestController::staticFunctions):
* DumpRenderTree/LayoutTestController.h:
(LayoutTestController):
* DumpRenderTree/blackberry/LayoutTestControllerBlackBerry.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/chromium/LayoutTestController.cpp:
(LayoutTestController::LayoutTestController):
(LayoutTestController::setXSSAuditorEnabled):
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/chromium/LayoutTestController.h:
(LayoutTestController):
* DumpRenderTree/efl/LayoutTestControllerEfl.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/gtk/LayoutTestControllerGtk.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/mac/LayoutTestControllerMac.mm:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/qt/LayoutTestControllerQt.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/qt/LayoutTestControllerQt.h:
(LayoutTestController):
* DumpRenderTree/win/LayoutTestControllerWin.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):
* DumpRenderTree/wx/LayoutTestControllerWx.cpp:
(LayoutTestController::evaluateScriptInIsolatedWorldAndReturnValue):

LayoutTests:

Testing executing a script and getting the result of that script.

* platform/chromium/http/tests/misc/execute-and-return-value-expected.txt: Added.
* platform/chromium/http/tests/misc/execute-and-return-value.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114974 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: https://bugs.webkit.org/show_bug.cgi?id=84649
RenderMathMLOperator currently ignores font families, fails 
to use Stix

Reviewed by Dan Bernstein.

This patch makes RenderMathMLOperator honor the font-family 
list. This means that by default, Stix glyphs will now be 
used for operators just like for other MathML content. 
Unfortunately, just doing that resulted in a bug because of 
the fragile hardcoded glyph sizes. The Stix vertical bar 
glyph is much smaller than the code assumed any glyphs would 
be. That code should be re-written, but in the meantime, I 
put a fix in place to try to make it work for small glyphs.

These new functions should be used instead of accessing
gGlyphHeight or gGlyphLineHeight directly. If the glyph is
smaller than the expected hardcoded value, then the actual
glyph height is used, and a new line height based on the
glyph height is used.
(WebCore::RenderMathMLOperator::glyphHeightForCharacter):
(WebCore::RenderMathMLOperator::lineHeightForCharacter):

Use the style's FontDescription to honor the font family
list and the style's FontSelector to honor @font-face.
Also use glyphHeightForCharacter() instead of gGlyphHeight. 
And now that createGlyph() takes a lineHeight, use 
lineHeightForCharacter() to determine the right value. 
(WebCore::RenderMathMLOperator::updateFromElement):

size was an ambiguous variable name, so I renamed it to the 
more accurate maxHeightForRenderer. This function also now
takes a lineHeight instead of using gGlyphLineHeight. And
again, use the style's FontDescription and FontSelector.
(WebCore::RenderMathMLOperator::createStackableStyle):

Re-name size to maxHeightForRenderer, and take lineHeight as 
a parameter.
(WebCore::RenderMathMLOperator::createGlyph):
* rendering/mathml/RenderMathMLOperator.h:
(RenderMathMLOperator):

LayoutTests: https://bugs.webkit.org/show_bug.cgi?id=84649
RenderMathMLOperator currently ignores font families, fails to use Stix

Reviewed by Dan Bernstein.

 Metrics are slightly different now that Stix glyphs are being used for operators.
* platform/mac/mathml/presentation/fenced-expected.txt:
* platform/mac/mathml/presentation/fenced-mi-expected.txt:
* platform/mac/mathml/presentation/mo-expected.txt:
* platform/mac/mathml/presentation/mo-stretch-expected.txt:
* platform/mac/mathml/presentation/over-expected.txt:
* platform/mac/mathml/presentation/row-alignment-expected.txt:
* platform/mac/mathml/presentation/row-expected.txt:
* platform/mac/mathml/presentation/sub-expected.txt:
* platform/mac/mathml/presentation/subsup-expected.txt:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r114965.
http://trac.webkit.org/changeset/114965
https://bugs.webkit.org/show_bug.cgi?id=84665

Four new resource load delegate test failures (Requested by
jernoble on #webkit).

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

Source/WebCore:

* loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didFinishLoading):
(WebCore::SubresourceLoader::didFail):
(WebCore::SubresourceLoader::willCancel):
(WebCore::SubresourceLoader::releaseResources):

LayoutTests:

* http/tests/cache/cancel-during-failure-crash-expected.txt: Removed.
* http/tests/cache/cancel-during-failure-crash.html: Removed.
* platform/chromium-mac/security/block-test-expected.txt:
* platform/chromium-win/security/block-test-expected.txt:
* platform/gtk/security/block-test-expected.txt:
* platform/mac/security/block-test-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114976 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Explicitly mention Xcode version 4.3.2 in Mac debug instructions

Rubber-stamped by Eric Seidel.

The build location instructions at the top of page building/{debug-mac-uiprocess.html, debug.html}
are specific to Xcode 4.3.2.

* building/debug-mac-uiprocess.html: Substitute "Xcode 4.3.2" for "Xcode 4".
* building/debug.html: Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114978 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(113604): [Soup] Some pages that use synchronous XMLHttpRequests freeze the browser
https://bugs.webkit.org/show_bug.cgi?id=84560

Reviewed by Xan Lopez.

When kicking off a synchronous XMLHttpRequest, add one to the connection
limit. This ensures that when a page starts a synchronous request, while
already at the connection limit the request will not deadlock.

* platform/network/soup/ResourceHandleSoup.cpp:
(WebCore::WebCoreSynchronousLoader::WebCoreSynchronousLoader): Accept a new SoupSession
argument so that we can get the correct SoupSession for the networking context. Bump
the connection limit.
(WebCore::WebCoreSynchronousLoader::~WebCoreSynchronousLoader): Decrement the connection limit.
(WebCore::WebCoreSynchronousLoader::adjustMaxConnections): Added this helper.
(WebCoreSynchronousLoader): Added a new SoupSession member.
(WebCore::sessionFromContext): Added this helper.
(WebCore::ResourceHandleInternal::soupSession): Use the new sessionFromContext helper.
(WebCore::ResourceHandle::loadResourceSynchronously): Pass the SoupSession from the NetworkingContext
to the synchronous loader.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114980 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: remove IDB(Index|ObjectStore)BackendImpl::get/getKey for IDBKey
https://bugs.webkit.org/show_bug.cgi?id=84285

Patch by Alec Flett <alecflett@chromium.org> on 2012-04-23
Reviewed by Dimitri Glazkov.

Source/WebCore:

No new tests required, this code is no longer called.

This is old code supporting IDBKey-based lookup, supplanted by
IDBKeyRange. Now that chromium IPC/proxy code has landed,
these functions can be removed.

* Modules/indexeddb/IDBIndexBackendInterface.h:
(IDBIndexBackendInterface):
* Modules/indexeddb/IDBObjectStoreBackendInterface.h:
(IDBObjectStoreBackendInterface):

Source/WebKit/chromium:

This is old code supporting IDBKey-based lookup, supplanted by
IDBKeyRange. Now that chromium IPC/proxy code has landed,
these functions can be removed.

* public/WebIDBIndex.h:
* public/WebIDBObjectStore.h:
* src/IDBIndexBackendProxy.cpp:
* src/IDBIndexBackendProxy.h:
(IDBIndexBackendProxy):
* src/IDBObjectStoreBackendProxy.cpp:
* src/IDBObjectStoreBackendProxy.h:
(IDBObjectStoreBackendProxy):
* src/WebIDBIndexImpl.cpp:
* src/WebIDBIndexImpl.h:
(WebIDBIndexImpl):
* src/WebIDBObjectStoreImpl.cpp:
* src/WebIDBObjectStoreImpl.h:
(WebIDBObjectStoreImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114981 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add notice about running xcode-select before using Xcode 4.3.2 command line tools

Rubber-stamped by Eric Seidel.

Before you can use the Xcode 4.3.2 command line tools, you must either run
sudo xcode-select -switch /Applications/Xcode.app or set the environment variable
DEVELOPER_DIR to point to the Xcode developer tools directory. 

* building/tools.html:


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