Unreviewed, rolling out r137027.
http://trac.webkit.org/changeset/137027

Precursor to rollout of 136975.

* dom/ElementRareData.h:
(ElementRareData):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137459 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r137022.
http://trac.webkit.org/changeset/137022

Precursor to rollout of 136975.

* rendering/svg/SVGResources.cpp:
(WebCore::SVGResources::buildCachedResources):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137460 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed gardening, remove duplicated expectations and fix broken expectations.

* platform/qt-4.8/TestExpectations:
* platform/qt-5.0-wk2/TestExpectations:
* platform/qt-mac/TestExpectations:
* platform/qt/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137461 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r137000.
http://trac.webkit.org/changeset/137000

Precursor to rolling out r136975.

* platform/chromium-linux/css3/filters/effect-reference-after-expected.png: Renamed from LayoutTests/platform/chromium-win/css3/filters/effect-reference-after-expected.png.
* platform/chromium-linux/css3/filters/effect-reference-delete-expected.png: Renamed from LayoutTests/platform/chromium-win/css3/filters/effect-reference-delete-expected.png.
* platform/chromium-linux/css3/filters/effect-reference-rename-expected.png: Renamed from LayoutTests/platform/chromium-win/css3/filters/effect-reference-rename-expected.png.
* platform/chromium-mac/css3/filters/effect-reference-after-expected.png: Removed.
* platform/chromium-mac/css3/filters/effect-reference-delete-expected.png: Removed.
* platform/chromium-mac/css3/filters/effect-reference-rename-expected.png: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137462 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r136975.
http://trac.webkit.org/changeset/136975
https://bugs.webkit.org/show_bug.cgi?id=90405

Correctness issues.

Source/WebCore:

* dom/Element.cpp:
* dom/Element.h:
(Element):
* dom/ElementRareData.h:
(ElementRareData):
(WebCore::ElementRareData::ElementRareData):
* platform/graphics/texmap/TextureMapperImageBuffer.cpp:
(WebCore::BitmapTextureImageBuffer::applyFilters):
* rendering/FilterEffectRenderer.cpp:
(WebCore::createCustomFilterEffect):
(WebCore::FilterEffectRenderer::buildReferenceFilter):
(WebCore::FilterEffectRenderer::build):
* rendering/FilterEffectRenderer.h:
(FilterEffectRenderer):
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateOrRemoveFilterEffectRenderer):
* rendering/RenderObject.cpp:
(WebCore::RenderObject::willBeDestroyed):
* rendering/svg/RenderSVGResourceContainer.cpp:
(WebCore::RenderSVGResourceContainer::registerResource):
* rendering/svg/SVGResources.cpp:
(WebCore::SVGResources::buildCachedResources):
* rendering/svg/SVGResourcesCache.cpp:
(WebCore::SVGResourcesCache::addResourcesFromRenderObject):
(WebCore::SVGResourcesCache::clientStyleChanged):
(WebCore::SVGResourcesCache::resourceDestroyed):
* svg/SVGDocumentExtensions.cpp:
(WebCore::SVGDocumentExtensions::addPendingResource):
(WebCore::SVGDocumentExtensions::isElementPendingResources):
(WebCore::SVGDocumentExtensions::isElementPendingResource):
(WebCore::SVGDocumentExtensions::removeElementFromPendingResources):
(WebCore::SVGDocumentExtensions::removeElementFromPendingResourcesForRemoval):
* svg/SVGDocumentExtensions.h:
(WebCore):
(SVGDocumentExtensions):
* svg/SVGElement.cpp:
(WebCore::SVGElement::hasPendingResources):
(WebCore):
(WebCore::SVGElement::setHasPendingResources):
(WebCore::SVGElement::clearHasPendingResourcesIfPossible):
* svg/SVGElement.h:
(SVGElement):
(WebCore::SVGElement::buildPendingResource):
* svg/SVGElementRareData.h:
(WebCore::SVGElementRareData::SVGElementRareData):
(WebCore::SVGElementRareData::hasPendingResources):
(WebCore::SVGElementRareData::setHasPendingResources):
(SVGElementRareData):
* svg/SVGStyledElement.cpp:
(WebCore::SVGStyledElement::buildPendingResourcesIfNeeded):

LayoutTests:

* css3/filters/effect-reference-after-expected.txt: Removed.
* css3/filters/effect-reference-after.html: Removed.
* css3/filters/effect-reference-delete-crash-expected.txt: Removed.
* css3/filters/effect-reference-delete-crash.html: Removed.
* css3/filters/effect-reference-delete-expected.txt: Removed.
* css3/filters/effect-reference-delete.html: Removed.
* css3/filters/effect-reference-rename-expected.txt: Removed.
* css3/filters/effect-reference-rename.html: Removed.
* css3/filters/effect-reference-reset-style-delete-crash-expected.txt: Removed.
* css3/filters/effect-reference-reset-style-delete-crash.html: Removed.
* css3/filters/script-tests/effect-reference-delete-crash.js: Removed.
* css3/filters/script-tests/effect-reference-reset-style-delete-crash.js: Removed.
* platform/chromium-linux/css3/filters/effect-reference-after-expected.png: Removed.
* platform/chromium-linux/css3/filters/effect-reference-delete-expected.png: Removed.
* platform/chromium-linux/css3/filters/effect-reference-rename-expected.png: Removed.
* svg/filters/filter-cycle-expected.html: Removed.
* svg/filters/filter-cycle.html: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137463 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: [Crash] Clear cached stylesheet rules in InspectorStyleSheet::deleteRule()
https://bugs.webkit.org/show_bug.cgi?id=104806

Reviewed by Vsevolod Vlasov.

Source/WebCore:

Cached rules (m_flatRules) should get cleared whenever a rule is deleted.

Test: inspector/styles/undo-add-rule-crash.html

* inspector/InspectorStyleSheet.cpp:
(WebCore::InspectorStyleSheet::deleteRule):

LayoutTests:

* inspector/styles/undo-add-rule-crash-expected.txt: Added.
* inspector/styles/undo-add-rule-crash.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137464 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Unreviewed gardening.

Rebaselining tests with anonymous empty blocks aftter r137336.
Floating elements rebaselined after r137331.
Newly intrduced reftest is failing, introduced in r137368.
Unskipping a few new passed that had something to do with AC.

* platform/efl/TestExpectations:
* platform/efl/css1/formatting_model/floating_elements-expected.png: Added.
* platform/efl/css1/formatting_model/floating_elements-expected.txt:
* platform/efl/fast/css-generated-content/table-row-group-to-inline-expected.png:
* platform/efl/fast/css-generated-content/table-row-group-to-inline-expected.txt:
* platform/efl/fast/css/empty-generated-content-expected.png:
* platform/efl/fast/css/empty-generated-content-expected.txt:
* platform/efl/http/tests/misc/acid3-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137465 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Crash in InspectorDOMAgent::pushNodePathToFrontend when inspecting document with CSS generated content
https://bugs.webkit.org/show_bug.cgi?id=104780

Patch by Antoine Quint <graouts@apple.com> on 2012-12-12
Reviewed by Pavel Feldman.

Source/WebCore:

The pushNodePathForRenderLayerToFrontend() method added to InspectorDOMAgent naively assumed
that all RenderLayers have a Node associated to them. However, in the case of CSS generated
content, that will not be the case and we would call into pushNodePathToFrontend() with a 0
parameter that would hit the first ASSERT in this method. We're now checking that we indeed
have an associated node for the provided RenderLayer and return 0 in case we don't, without
calling into pushNodePathToFrontend().

Test: inspector-protocol/layer-tree-generated-content.html

* inspector/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::pushNodePathForRenderLayerToFrontend):

LayoutTests:

Adding a new test for the LayerTreeAgent to check that it does not crash when inspecting
a page with CSS generated content, and correctly returns nodeId === 0 in the situation
where there is no Node associated with a given RenderLayer.

* inspector-protocol/layer-tree-generated-content-expected.txt: Added.
* inspector-protocol/layer-tree-generated-content.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137466 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL [WebGL] [Wk2] Resizing the canvas breaks WebGL.
https://bugs.webkit.org/show_bug.cgi?id=104535.

Patch by Kondapally Kalyan <kalyan.kondapally@intel.com> on 2012-12-12
Reviewed by Kenneth Rohde Christiansen.

GraphicsContext3DEfl does not re-create the surface on canvas resize, this
conflicted with the logic in coordinated graphics Layer.
CoordinatedGraphicsLayer checks for GraphicsSurfaceToken to decide if the surface
in UI-Process should be recreated or not. With this
patch we also check for size of the platform Layer.

Source/WebCore:

* platform/graphics/efl/GraphicsContext3DEfl.cpp:
(WebCore::GraphicsContext3D::createGraphicsSurfaces):
* platform/graphics/efl/GraphicsContext3DPrivate.cpp:
(GraphicsContext3DPrivate::didResizeCanvas):
(GraphicsContext3DPrivate::platformLayerSize):
* platform/graphics/efl/GraphicsContext3DPrivate.h:
(GraphicsContext3DPrivate):

Source/WebKit2:

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::setContentsToCanvas):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayer):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137467 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo.
https://bugs.webkit.org/show_bug.cgi?id=104796

Reviewed by Yury Semikhatsky.

It was not a good idea to introduce a fake root MemoryObjectInfo.
It makes a problem when we visit an object without its own MemoryObjectType.

Example: RenderBox has a global pointer to a hash map.
HashMap doesn't have its own object type because it is a generic container.
It will inherit object type from the fake root memory object info.
The same could happen for another container in another class with other MemoryObjectType.

This fact forces me to create custom process method for root objects
because they need to have their own MemoryObjectInfo with customisable memory object type.

Source/JavaScriptCore:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

Source/WebCore:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* inspector/MemoryInstrumentationImpl.cpp:
(WebCore::MemoryInstrumentationImpl::processDeferredObjects):
(WebCore::MemoryInstrumentationImpl::deferObject):
(WebCore::MemoryInstrumentationImpl::reportMemoryUsage):
* inspector/MemoryInstrumentationImpl.h:
(MemoryInstrumentationImpl):

Source/WTF:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* wtf/MemoryInstrumentation.cpp:
(WTF::MemoryInstrumentation::MemoryInstrumentation):
(WTF::MemoryInstrumentation::WrapperBase::WrapperBase):
(WTF::MemoryInstrumentation::WrapperBase::process):
(WTF::MemoryInstrumentation::WrapperBase::processRootObjectRef):
(WTF):
* wtf/MemoryInstrumentation.h:
(WTF::MemoryInstrumentation::addRootObject):
(MemoryInstrumentation):
(WrapperBase):
(WTF::MemoryInstrumentation::WrapperBase::~WrapperBase):
(Wrapper):
(OwningTraits):
(WTF::MemoryInstrumentation::OwningTraits::addRootObject):
(WTF::MemoryInstrumentation::addObjectImpl):
(WTF::::Wrapper):
(WTF::::callReportMemoryUsage):

Tools:

* TestWebKitAPI/Tests/WTF/MemoryInstrumentationTest.cpp:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137468 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Add sections documentation to WebKit2 GTK+ API
https://bugs.webkit.org/show_bug.cgi?id=104484

Reviewed by Martin Robinson.

Many of the sections in the WebKit2 GTK+ API documentation were
missing. This commit adds new documentation, in some cases
adapting it from WebKitGtk+ and in others writing it from the
scratch.

It also removes the WebKitWebViewBase class from the documentation
index, since it is not really relevant.

* UIProcess/API/gtk/WebKitBackForwardListItem.cpp:
* UIProcess/API/gtk/WebKitContextMenu.cpp:
* UIProcess/API/gtk/WebKitContextMenuItem.cpp:
* UIProcess/API/gtk/WebKitCookieManager.cpp:
* UIProcess/API/gtk/WebKitDownload.cpp:
* UIProcess/API/gtk/WebKitError.cpp:
* UIProcess/API/gtk/WebKitFaviconDatabase.cpp:
* UIProcess/API/gtk/WebKitFindController.cpp:
* UIProcess/API/gtk/WebKitFormSubmissionRequest.cpp:
* UIProcess/API/gtk/WebKitPlugin.cpp:
* UIProcess/API/gtk/WebKitPrintOperation.cpp:
* UIProcess/API/gtk/WebKitSecurityManager.cpp:
* UIProcess/API/gtk/WebKitURIRequest.cpp:
* UIProcess/API/gtk/WebKitURIResponse.cpp:
* UIProcess/API/gtk/WebKitURISchemeRequest.cpp:
* UIProcess/API/gtk/WebKitVersion.cpp:
* UIProcess/API/gtk/WebKitWebContext.cpp:
* UIProcess/API/gtk/WebKitWebInspector.cpp:
* UIProcess/API/gtk/WebKitWebResource.cpp:
(webkit_web_resource_class_init):
* UIProcess/API/gtk/WebKitWebView.cpp:
* UIProcess/API/gtk/docs/webkit2gtk-docs.sgml:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137469 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix slow test so it passes consistently now that we have multipart support
in soup.

Reviewed by Martin Robinson.

The multipart-wait-before-boundary test waits for 30 seconds before
sending the boundary. That is a bit long in itself, but it is exactly
the timeout used for slow tests in some platforms. This change reduces
the wait to 20 seconds, which should be enough for the test, and marks
the test as slow for GTK+.

* http/tests/multipart/resources/multipart-wait-before-boundary.php: wait
for 20 seconds instead of 30, before sending the boundary.
* platform/gtk/TestExpectations: mark test above as slow.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137470 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, GTK gardening. Flag some flaky media tests after r137271.

* platform/gtk/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137471 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: instrument static parts of RenderBlock and RenderBox
https://bugs.webkit.org/show_bug.cgi?id=104660

Reviewed by Yury Semikhatsky.

Plain vanilla instrumentation.

* dom/WebCoreMemoryInstrumentation.cpp:
(WebCore):
(WebCore::WebCoreMemoryInstrumentation::reportMemoryUsage):
* dom/WebCoreMemoryInstrumentation.h:
(WebCoreMemoryTypes):
(WebCoreMemoryInstrumentation):
(WebCore):
* inspector/InspectorMemoryAgent.cpp:
(WebCore::InspectorMemoryAgent::getProcessMemoryDistribution):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::reportStaticMembersMemoryUsage):
(WebCore):
* rendering/RenderBlock.h:
(RenderBlock):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::reportStaticMembersMemoryUsage):
(WebCore):
* rendering/RenderBox.h:
(RenderBox):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use render box background over border draw strategy in cases with background-image
https://bugs.webkit.org/show_bug.cgi?id=103409

Reviewed by Simon Fraser.

Source/WebCore:

The BackgroundOverBorderBleedAvoidance mode was not being used in
cases where the background is an opaque image. It was also not
being used in cases with multiple layers. The multiple layer
case is now safe with respect to color bleeding if the top layer
is opaque, thank to the recent addition of layer occlusion culling
in r135629.

No new tests. Testing already covered by the following tests:
fast/backgrounds/background-opaque-images-over-color.html
fast/backgrounds/gradient-background-leakage-2.html

* rendering/RenderBox.cpp:
(WebCore::RenderBox::determineBackgroundBleedAvoidance):
(WebCore::RenderBox::backgroundHasOpaqueTopLayer):
* rendering/RenderBox.h:
(RenderBox):

LayoutTests:

Added image failure expectation for
fast/backgrounds/gradient-background-leakage-2.html which needs
new baselines.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137473 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add some entries in the watchlist, and register me for them.

* Scripts/webkitpy/common/config/watchlist:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137474 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Possibility to turn off accessibility feature for WebKit-EFL.
https://bugs.webkit.org/show_bug.cgi?id=103036

Patch by Krzysztof Czech <k.czech@samsung.com> on 2012-12-12
Reviewed by Laszlo Gombos.

Guard dependencies for accessibility (ATK), so that they can be turned off.

.:

* Source/cmake/OptionsEfl.cmake:
* Source/cmake/WebKitFeatures.cmake:

Source/WebCore:

No new tests as there is no new functionality.

* PlatformEfl.cmake:
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::AccessibilityObject):
* accessibility/AccessibilityObject.h:
(AccessibilityObject):

Tools:

* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
(AccessibilityUIElement):
* WebKitTestRunner/PlatformEfl.cmake:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137475 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaseline after change to Chromium compositor

Unreviewed gardening.

* platform/chromium-linux/compositing/reflections/reflection-in-composited-expected.png:
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137476 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Copying text with ruby inserts new lines around rt elements
https://bugs.webkit.org/show_bug.cgi?id=104765

Reviewed by Dan Bernstein.

Source/WebCore: 

Don't emit new lines before and after rt.

Test: editing/pasteboard/copy-paste-ruby-text.html

* editing/TextIterator.cpp:
(WebCore::shouldEmitNewlinesBeforeAndAfterNode):

LayoutTests: 

Added a regression test and rebaseline a test as expected.

* editing/pasteboard/copy-paste-ruby-text-expected.txt: Added.
* editing/pasteboard/copy-paste-ruby-text-with-block-expected.txt: Added.
* editing/pasteboard/copy-paste-ruby-text-with-block.html: Added.
* editing/pasteboard/copy-paste-ruby-text.html: Added.
* editing/selection/paragraph-with-ruby-expected.txt:  new lines around "annotation" has been removed
as expected.
* fast/block/line-layout/selection-highlight-crash-expected.txt:
* fast/ruby/after-doesnt-crash-expected.txt:
* fast/ruby/before-doesnt-crash-expected.txt:
* fast/ruby/parse-rp-expected.txt:
* fast/ruby/ruby-line-height-expected.txt:
* fast/ruby/ruby-text-indent-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-1-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-2-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-3-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-1-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-2-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-3-expected.txt:
* fast/ruby/text-emphasis-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137477 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Grid Layout] Implement CSS parsing and handling for min-content and max-content
https://bugs.webkit.org/show_bug.cgi?id=104747

Reviewed by Alexis Menard.

Source/WebCore:

This change adds -webkit-min-content and -webkit-max-content to our <track-breadth> parsing.
The rendering is not plugged in and will probably depend on bug 103311.

Tests: fast/css-grid-layout/grid-columns-rows-get-set-multiple.html:
       fast/css-grid-layout/grid-columns-rows-get-set.html:

* css/CSSParser.cpp:
(WebCore::CSSParser::parseGridBreadth):
* css/StyleResolver.cpp:
(WebCore::createGridTrackBreadth):
Straight-forward extension of the new code. We were already serializing back properly
so no need to touch CSSComputedStyleDeclaration.

LayoutTests:

Extended the 2 tests to cover -webkit-min-content and -webkit-max-content.

* fast/css-grid-layout/grid-columns-rows-get-set-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple.html:
* fast/css-grid-layout/grid-columns-rows-get-set.html:
* fast/css-grid-layout/resources/grid-columns-rows-get-set-multiple.js:
* fast/css-grid-layout/resources/grid-columns-rows-get-set.js:


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