Unreviewed.  Rolled DEPS.

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

* DEPS:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131493 268f45cc-cd09-0410-ab3c-d52691b4dbfc
MediaStream API: Add the chromium API for RTCDataChannel
https://bugs.webkit.org/show_bug.cgi?id=99435

Reviewed by Adam Barth.

Source/Platform:

Adding WebRTCDataChannel.

* Platform.gypi:
* chromium/public/WebRTCDataChannel.h: Added.
(WebCore):
(WebKit):
(WebRTCDataChannel):
(ExtraData):
(WebKit::WebRTCDataChannel::ExtraData::~ExtraData):
(WebKit::WebRTCDataChannel::WebRTCDataChannel):
(WebKit::WebRTCDataChannel::~WebRTCDataChannel):
(WebKit::WebRTCDataChannel::operator=):
(WebKit::WebRTCDataChannel::isNull):
* chromium/public/WebRTCPeerConnectionHandler.h:
(WebKit):
(WebRTCPeerConnectionHandler):
(WebKit::WebRTCPeerConnectionHandler::openDataChannel):
(WebKit::WebRTCPeerConnectionHandler::sendStringData):
(WebKit::WebRTCPeerConnectionHandler::sendRawData):
(WebKit::WebRTCPeerConnectionHandler::closeDataChannel):

Source/WebCore:

Adding WebRTCDataChannel.

Test: fast/mediastream/RTCPeerConnection-datachannel.html

* WebCore.gypi:
* platform/chromium/support/WebRTCDataChannel.cpp: Added.
(WebKit):
(ExtraDataContainer):
(WebKit::ExtraDataContainer::ExtraDataContainer):
(WebKit::ExtraDataContainer::extraData):
(WebKit::WebRTCDataChannel::WebRTCDataChannel):
(WebKit::WebRTCDataChannel::initialize):
(WebKit::WebRTCDataChannel::assign):
(WebKit::WebRTCDataChannel::reset):
(WebKit::WebRTCDataChannel::operator PassRefPtr<WebCore::RTCDataChannelDescriptor>):
(WebKit::WebRTCDataChannel::operator WebCore::RTCDataChannelDescriptor*):
(WebKit::WebRTCDataChannel::extraData):
(WebKit::WebRTCDataChannel::setExtraData):
(WebKit::WebRTCDataChannel::label):
(WebKit::WebRTCDataChannel::reliable):
(WebKit::WebRTCDataChannel::setBufferedAmount):
(WebKit::WebRTCDataChannel::readyStateChanged):
(WebKit::WebRTCDataChannel::dataArrived):
(WebKit::WebRTCDataChannel::error):
* platform/mediastream/chromium/RTCPeerConnectionHandlerChromium.cpp:
(WebCore::RTCPeerConnectionHandlerChromium::negotiationNeeded):
(WebCore::RTCPeerConnectionHandlerChromium::didGenerateICECandidate):
(WebCore):
(WebCore::RTCPeerConnectionHandlerChromium::didChangeReadyState):
(WebCore::RTCPeerConnectionHandlerChromium::didChangeICEState):
(WebCore::RTCPeerConnectionHandlerChromium::didRemoveRemoteStream):

Source/WebKit/chromium:

Adding checks for RTCDataChannel.

* src/AssertMatchingEnums.cpp:

Tools:

Adding mock support for WebRTCDataChannel.

* DumpRenderTree/chromium/MockWebRTCPeerConnectionHandler.cpp:
(StringDataTask):
(StringDataTask::StringDataTask):
(CharPtrDataTask):
(CharPtrDataTask::CharPtrDataTask):
(DataChannelReadyStateTask):
(DataChannelReadyStateTask::DataChannelReadyStateTask):
(RTCPeerConnectionReadyStateTask):
(RTCPeerConnectionReadyStateTask::RTCPeerConnectionReadyStateTask):
(MockWebRTCPeerConnectionHandler::MockWebRTCPeerConnectionHandler):
(MockWebRTCPeerConnectionHandler::initialize):
(MockWebRTCPeerConnectionHandler::stop):
(MockWebRTCPeerConnectionHandler::openDataChannel):
(MockWebRTCPeerConnectionHandler::closeDataChannel):
(MockWebRTCPeerConnectionHandler::sendStringData):
(MockWebRTCPeerConnectionHandler::sendRawData):
* DumpRenderTree/chromium/MockWebRTCPeerConnectionHandler.h:
(MockWebRTCPeerConnectionHandler):

LayoutTests:

Adding tests for RTCDataChannel.

* fast/mediastream/RTCPeerConnection-datachannel-expected.txt: Added.
* fast/mediastream/RTCPeerConnection-datachannel.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131494 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Android: Need a way to get appropriate font for some specific characters.
https://bugs.webkit.org/show_bug.cgi?id=67587

Reviewed by Adam Barth.

Source/WebCore:

Use the new Skia API SkGetFallbackFamilyNameForChar() to get the family name for individual characters.

No new tests. The following existing tests pass with the change:
fast/writing-mode/vertical-subst-font-vert-no-dflt.html
fast/dynamic/text-combine.html
fast/writing-mode/japanese-rl-text.html
fast/writing-mode/japanese-rl-selection.html
fast/writing-mode/japanese-lr-text.html
fast/repaint/japanese-rl-selection-repaint.html
fast/writing-mode/border-vertical-lr.html

* platform/graphics/chromium/FontCacheAndroid.cpp:
(WebCore::FontCache::getFontDataForCharacters):

Source/WebKit/chromium:

Define ENABLE_OPENTYPE_VERTICAL=1 on Android.

* features.gypi:

LayoutTests:

Removed unnecessary rebaselines.
Removed failure expectations for the tests now pass.
Added pixel only rebaselines for some of the above tests.

* platform/chromium-android/fast/repaint/japanese-rl-selection-repaint-expected.png: Added. New pixel rebaseline.
* platform/chromium-android/fast/writing-mode/japanese-lr-selection-expected.png: Removed. Unnecessary rebaseline.
* platform/chromium-android/fast/writing-mode/japanese-lr-selection-expected.txt: Removed. Unnecessary rebaseline.
* platform/chromium-android/fast/writing-mode/japanese-rl-selection-expected.png: Added. New pixel rebaseline.
* platform/chromium-android/fast/writing-mode/japanese-rl-text-with-broken-font-expected.png: Removed. Unnecessary rebaseline.
* platform/chromium/TestExpectations: Removed the failure expectations for the tests now pass.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131495 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove Platform.h include from the header files.
https://bugs.webkit.org/show_bug.cgi?id=98665

Patch by Dima Gorbik <dgorbik@apple.com> on 2012-10-16
Reviewed by Eric Seidel.

We don't want other clients that include WebKit headers to know about Platform.h.

Source/JavaScriptCore:

* API/tests/minidom.c:
* API/tests/testapi.c:

Source/WebCore:

No new tests.

* platform/MemoryPressureHandler.h:
* platform/graphics/filters/arm/FECompositeArithmeticNEON.h:
* platform/graphics/filters/arm/FEGaussianBlurNEON.h:
* platform/graphics/filters/arm/FELightingNEON.h:

Source/WTF:

* wtf/Assertions.h:
* wtf/MainThread.h:

Tools:

* DumpRenderTree/mac/MockGeolocationProvider.mm:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131496 268f45cc-cd09-0410-ab3c-d52691b4dbfc
input[type=range] as a flex item renders thumb at wrong position
https://bugs.webkit.org/show_bug.cgi?id=98666

Reviewed by Ojan Vafai.

Source/WebCore:

Replace RenderSlider implementation with new flexbox and clean up the shadow DOM.
The previous code was trying to set the height to 100% and had a bunch of hacks in
the renderer code to set an explicit height. Using the new flexbox allows us to
remove these renderer hacks.

Test: css3/flexbox/flexitem-stretch-range.html

* css/html.css:
(input[type="range"]::-webkit-slider-container, input[type="range"]::-webkit-media-slider-container): Use new flexbox.
(input[type="range"]::-webkit-slider-runnable-track): Use new flexbox.
(input[type="range"]::-webkit-slider-thumb, input[type="range"]::-webkit-media-slider-thumb): Remove relative positioning since we're
no longer setting top/left in the layout code.
* css/mediaControlsChromium.css: Remove redundant styles and bottom: 1px hack.
* css/mediaControlsChromiumAndroid.css: Remove redundant styles and bottom: 1px hack.
* html/RangeInputType.cpp:
(WebCore::RangeInputType::listAttributeTargetChanged): We need to force a layout
since the height of the control should change when adding/removing a datalist.
* html/shadow/SliderThumbElement.cpp:
(WebCore::RenderSliderContainer::RenderSliderContainer): Use new flexbox.
(WebCore::RenderSliderContainer::computeLogicalHeight): Rather than setting style()->height() in layout, just compute the correct
height when asked.  If we have a datalist, we increase the height (same code as before).  If we're vertical,
we use the intrinsic size.
(WebCore::RenderSliderContainer::layout): Remove extra layout code, but handle the position of the thumb.
This used to be handled in the thumb's layout method, but I deleted that.
* html/shadow/SliderThumbElement.h:
* rendering/RenderSlider.cpp:
(WebCore::RenderSlider::RenderSlider): Use new flexbox.
(WebCore::RenderSlider::layout): Set the limiter size to the size of the thumb. This is necessary
for fast/css/unknown-pseudo-element-matching.html which tries to set the height of the thumb to 1px
and expects the input to also have a height of 1px.  It worked before because the height of the input
didn't depend on the height of its children.
* rendering/RenderSlider.h: Fix indentation.
(RenderSlider): Use new flexible box.

LayoutTests:

Changing the render tree to use RenderFlexibleBox instead of RenderDeprecatedFlexibleBox
and not using a RenderLayer unless noted otherwise.

* css3/flexbox/flexitem-stretch-range-expected.html: Added.
* css3/flexbox/flexitem-stretch-range.html: Added. New test to verify stretched flex item has the
thumb in the correct place.
* platform/chromium-linux/fast/dom/HTMLInputElement/input-slider-update-expected.txt:
* platform/chromium-linux/fast/dom/HTMLInputElement/input-slider-update-styled-expected.txt:
* platform/chromium-linux/fast/forms/box-shadow-override-expected.txt:
* platform/chromium-linux/fast/forms/datalist/input-appearance-range-with-datalist-expected.png: Changed the default height to
129px for vertical controls. This makes more sense than having a height of 100%.
* platform/chromium-linux/fast/forms/input-appearance-height-expected.txt:
* platform/chromium-linux/fast/forms/range/input-appearance-range-expected.png: The thumb now appears below the
focus ring. This matches other form controls like buttons and textareas.
* platform/chromium-linux/fast/forms/range/input-appearance-range-expected.txt:
* platform/chromium-linux/fast/forms/range/range-thumb-height-percentage-expected.txt:
* platform/chromium-linux/fast/forms/range/slider-padding-expected.txt:
* platform/chromium-linux/fast/forms/range/slider-thumb-shared-style-expected.txt:
* platform/chromium-linux/fast/forms/range/slider-thumb-stylability-expected.txt:
* platform/chromium-linux/fast/hidpi/video-controls-in-hidpi-expected.txt:
* platform/chromium-linux/fast/multicol/client-rects-expected.txt:
* platform/chromium-linux/fast/repaint/slider-thumb-drag-release-expected.txt:
* platform/chromium-linux/fast/repaint/slider-thumb-float-expected.txt:
* platform/chromium-linux/media/track/track-cue-rendering-vertical-expected.txt:
* platform/chromium-win/fast/layers/video-layer-expected.txt:
* platform/chromium-win/media/audio-controls-rendering-expected.txt:
* platform/chromium-win/media/audio-repaint-expected.txt:
* platform/chromium-win/media/controls-after-reload-expected.txt:
* platform/chromium-win/media/controls-strict-expected.txt:
* platform/chromium-win/media/controls-styling-expected.txt:
* platform/chromium-win/media/controls-styling-strict-expected.txt:
* platform/chromium-win/media/controls-without-preload-expected.txt:
* platform/chromium-win/media/media-controls-clone-expected.txt:
* platform/chromium-win/media/media-document-audio-repaint-expected.txt:
* platform/chromium-win/media/track/track-cue-rendering-horizontal-expected.txt:
* platform/chromium-win/media/video-controls-rendering-expected.txt:
* platform/chromium-win/media/video-display-toggle-expected.txt:
* platform/chromium-win/media/video-empty-source-expected.txt:
* platform/chromium-win/media/video-no-audio-expected.txt:
* platform/chromium-win/media/video-playing-and-pause-expected.txt:
* platform/chromium-win/media/video-zoom-controls-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131497 268f45cc-cd09-0410-ab3c-d52691b4dbfc
lots-of-objects.html is flaky crashing on the webkit.org mac bot.
http://code.google.com/p/chromium/issues/detail?id=46603

Unreviewed gardening.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131498 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Init timeout flag in ResourceErrorMac
https://bugs.webkit.org/show_bug.cgi?id=99478

Reviewed by Alexey Proskuryakov.

On construction from platform error types, initialize the timeout flag
to true if the error results from a timeout.

No new tests, covered by tests that will be added in bug 74802.

* platform/network/mac/ResourceErrorMac.mm:
(WebCore::ResourceError::platformLazyInit): Initializing timeout flag if the error was a timeout.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131499 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Document::adoptNode shouldn't special-case <iframe>
https://bugs.webkit.org/show_bug.cgi?id=99247

Reviewed by Ryosuke Niwa.

Source/WebCore:

The special case was added in http://trac.webkit.org/changeset/75293 to
fix a bug with magic iframes. Originally, I planned to remove this
special case, but further investigation reveals that other browsers
throw exceptions for other frame owner elements as well. Now we treat
all frame owner elements the same way.

Test: fast/frames/adopt-object-into-itself.html

* dom/Document.cpp:
(WebCore::Document::adoptNode):

LayoutTests:

Test that adopting an object element into itself also throws an
exception.

* fast/frames/adopt-object-into-itself-expected.txt: Added.
* fast/frames/adopt-object-into-itself.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131500 268f45cc-cd09-0410-ab3c-d52691b4dbfc
GetScopedVar CSE matches dead GetScopedVar's leading to IR corruption
https://bugs.webkit.org/show_bug.cgi?id=99470
<rdar://problem/12363698>

Source/JavaScriptCore: 

Reviewed by Mark Hahnenberg.

All it takes is to follow the "if (!shouldGenerate) continue" idiom and everything will be OK.

* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::globalVarLoadElimination):
(JSC::DFG::CSEPhase::scopedVarLoadElimination):
(JSC::DFG::CSEPhase::globalVarWatchpointElimination):
(JSC::DFG::CSEPhase::getByValLoadElimination):
(JSC::DFG::CSEPhase::checkStructureElimination):
(JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
(JSC::DFG::CSEPhase::getByOffsetLoadElimination):

LayoutTests: 

Rubber stamped by Mark Hahnenberg.

* fast/js/dfg-cse-dead-get-scoped-var-expected.txt: Added.
* fast/js/dfg-cse-dead-get-scoped-var.html: Added.
* fast/js/jsc-test-list:
* fast/js/script-tests/dfg-cse-dead-get-scoped-var.js: Added.
(foo.return.if):
(foo):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131501 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Some #include hygiene
https://bugs.webkit.org/show_bug.cgi?id=99500

Reviewed by Tony Chang.

Clean up some #includes, mostly related to GraphicsLayer.h. In many
cases this can be replaced by PlatformLayer.h.

Remove an #include of PluginViewBase.h from Page.h, which was a source
of #include fan-out.

* html/canvas/CanvasRenderingContext2D.h:
* page/Page.h:
* page/scrolling/ScrollingCoordinator.h:
* page/scrolling/ScrollingStateNode.h:
* page/scrolling/mac/ScrollingStateNodeMac.mm:
* platform/graphics/GraphicsContext3D.h:
* platform/graphics/MediaPlayer.h:
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
* platform/graphics/gpu/DrawingBuffer.h:
* platform/graphics/mac/MediaPlayerPrivateQTKit.mm:
* plugins/PluginViewBase.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131502 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove special-case flooring of baselinePosition for replaced elements in InlineFlowBox::placeBoxesInBlockDirection
https://bugs.webkit.org/show_bug.cgi?id=99376

Reviewed by Levi Weintraub.

Source/WebCore:

In r122769 (bug 91410) we added a special-case handling for
replaced elements in InlineFlowBox::placeBoxesInBlockDirection
to work around positioning issues in a couple of svg tests.
This was needed to compensate for a workaround in the table
painting code that was fixed in r131358 (bug 99364). As such the
special-case handling for replaced elements is no longer needed
in InlineFlowBox::placeBoxesInBlockDirection.

Furthermore this caused problems with caret repainting leaving
residual pixels which motivated this change.

No new tests, have not been able to write a repaint test to
demonstrate the caret repaint issue.

* rendering/InlineFlowBox.cpp:
(WebCore::InlineFlowBox::placeBoxesInBlockDirection):

LayoutTests:

* platform/chromium/TestExpectations:


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