2013-01-30 Lucas Forschler Merge r138606 2013-01-01 Dan Bernstein Update copyright strings Reviewed by Sam Weinig. * Info.plist: 2012-12-12 Lucas Forschler Merge r137393 2012-12-11 Tim Horton -webkit-svg-shadow radius changes don't cause children's boundaries to be recomputed https://bugs.webkit.org/show_bug.cgi?id=104722 Reviewed by Simon Fraser. Changes to -webkit-svg-shadow currently cause a relayout of the directly affected renderer and its parents, but not its children. However, children have the shadow radius baked into their cached boundaries, so these need to be invalidated. Test: svg/repaint/repaint-webkit-svg-shadow-container.html * rendering/RenderObject.h: Expose needsBoundariesUpdate(). * rendering/svg/RenderSVGContainer.h: Expose needsBoundariesUpdate(). * rendering/svg/RenderSVGImage.h: Expose needsBoundariesUpdate(). * rendering/svg/RenderSVGRoot.h: Expose needsBoundariesUpdate(). * rendering/svg/RenderSVGShape.h: Expose needsBoundariesUpdate(). * rendering/svg/SVGRenderSupport.cpp: (WebCore::SVGRenderSupport::layoutChildren): If the renderer has a shadow and is in needs of a boundaries update, mark children as needing boundaries updates too. 2012-11-29 Simon Fraser Merge r136174 2012-11-29 Simon Fraser Avoid painting lots of small rects in WebLayer painting https://bugs.webkit.org/show_bug.cgi?id=103673 Reviewed by Tim Horton. r109186 added code in drawLayerContents() to enumerate over the rects in the CALayer's dirty region, and paint them individually. This was done to help performance on the IE Maze Solver test. On large, complex pages like Facebook, the overhead of traversing the RenderLayer tree for painting is such that it's better to paint a single, or fewer rects rather than lots of little ones. So adopt a heuristic similar to that in DrawingArea, where if the combined area of the small rects is 75% or more of the combined rect, just paint the combined rect. Also paint the combined rect if there are more than 5 individual rects. I verified that this preserves the optimization for IE Maze Solver. * platform/graphics/mac/WebLayer.mm: (drawLayerContents): 2012-11-28 Lucas Forschler Windows build fix after r134704. * WebCore.vcproj/WebCore.vcproj: 2012-11-28 Lucas Forschler Merge r135992 2012-11-28 Roger Fong Initialize identity matrix in SimpleFontData::initGDIFont() properly. https://bugs.webkit.org/show_bug.cgi?id=103499 Reviewed by Timothy Horton. We are incorrectly initializing the matrix passed into GetGlyphOutline. This patch fixes MAT2 initialization to match the way we initialize the identity matrix in SimpleFontData::boundsForGDIGlyph and SimpleFontData::widthForGDIGlyph. * platform/graphics/win/SimpleFontDataWin.cpp: (WebCore::SimpleFontData::initGDIFont): 2012-11-28 Lucas Forschler Merge r119546 2012-06-05 Stephanie Lewis https://bugs.webkit.org/show_bug.cgi?id=88370 Memory sampler should trigger low memory signal Reviewed by Geoff Garen. No new tests. Verify by running stress test which crashes in a few minutes without the fix. Fix assumption in block code. We could get in a state where timer_event_source had already been released before the block ran. * platform/mac/MemoryPressureHandlerMac.mm: (WebCore::MemoryPressureHandler::holdOff): 2012-11-27 Lucas Forschler Merge r133338 2012-11-02 Anders Carlsson Add a PluginInactive plug-in unavailability reason https://bugs.webkit.org/show_bug.cgi?id=101089 Reviewed by Sam Weinig. This is to be used by Mac WebKit and WebKit2 shortly. * English.lproj/Localizable.strings: * platform/LocalizedStrings.cpp: (WebCore::inactivePluginText): (WebCore): * platform/LocalizedStrings.h: (WebCore): * platform/blackberry/LocalizedStringsBlackBerry.cpp: (WebCore::inactivePluginText): (WebCore): * platform/efl/LocalizedStringsEfl.cpp: (WebCore::inactivePluginText): (WebCore): * platform/gtk/LocalizedStringsGtk.cpp: (WebCore::inactivePluginText): (WebCore): * platform/qt/LocalizedStringsQt.cpp: (WebCore::inactivePluginText): (WebCore): * rendering/RenderEmbeddedObject.cpp: (WebCore::unavailablePluginReplacementText): * rendering/RenderEmbeddedObject.h: 2012-11-27 Lucas Forschler Merge r134666 2012-11-14 Mark Lam Fixed regressions due to adding JSEventListener::m_wrapper null checks. https://bugs.webkit.org/show_bug.cgi?id=102183. Reviewed by Geoffrey Garen. Fixed JSEventListener::operator==() to work within the contract that when m_wrapper is 0, m_jsFunction is also expected to be 0. Also fixed some typos in comments. No new tests. * bindings/js/JSEventListener.cpp: (WebCore::JSEventListener::visitJSFunction): (WebCore::JSEventListener::operator==): * bindings/js/JSEventListener.h: (WebCore::JSEventListener::jsFunction): 2012-11-27 Lucas Forschler Merge r134495 2012-11-13 Mark Lam JSEventListener should not access m_jsFunction when its wrapper is gone. https://bugs.webkit.org/show_bug.cgi?id=101985. Reviewed by Geoffrey Garen. Added a few null checks for m_wrapper before we do anything with m_jsFunction. No new tests. * bindings/js/JSEventListener.cpp: (WebCore::JSEventListener::initializeJSFunction): - Removed a now invalid assertion. m_wrapper is expected to have a valid non-zero value when jsFunction is valid. However, in the case of JSLazyEventListener (which extends JSEventListener), m_wrapper is initially 0 when m_jsFunction has not been realized yet. When JSLazyEventListener::initializeJSFunction() realizes m_jsFunction, it will set m_wrapper to an appropriate wrapper object. For this reason, JSEventListener::jsFunction() cannot do the null check on m_wrapper until after the call to initializeJSFunction. This, in turns, means that in the case of the non-lazy JSEventListener, initializeJSFunction() will also be called, and if the GC has collected the m_wrapper but the JSEventListener has not been removed yet, it is possible to see a null m_wrapper while m_jsFunction contains a non-zero stale value. Hence, this assertion of (m_wrapper || !m_jsFunction) in JSEventListener::initializeJSFunction() is not always true and should be removed. (WebCore::JSEventListener::visitJSFunction): (WebCore::JSEventListener::operator==): * bindings/js/JSEventListener.h: (WebCore::JSEventListener::jsFunction): 2012-11-26 Simon Fraser Merge r135080 2012-11-18 Simon Fraser Make convertToLayerCoords iterative, rather than recursive https://bugs.webkit.org/show_bug.cgi?id=102618 Reviewed by Antti Koivisto. RenderLayer::convertToLayerCoords() is a hot function on profiles. Change it to be iterative, rather than recursive, so that the bulk of the function can be inlined. Was tested with assertions against the old code during development. * rendering/RenderLayer.cpp: (WebCore::accumulateOffsetTowardsAncestor): (WebCore::RenderLayer::convertToLayerCoords): 2012-11-26 Lucas Forschler Merge r134327 2012-11-12 Roger Fong Web Inspector: Fix docking behaviour on Windows. https://bugs.webkit.org/show_bug.cgi?id=101978 Reviewed by Brian Weinstein. There are a number of problems with docking behaviour on Windows. For starters, it does not ever constrain the inspector's size properly while docked. It also does not properly set the whether or not the inspector can be docked/undocked. This patch fixes both issues. * inspector/InspectorFrontendClientLocal.cpp: (WebCore::InspectorFrontendClientLocal::frontendLoaded): Switch order of calling bringToFront and setDockingUnavailable. 2012-11-26 Simon Fraser Merge r135746 2012-11-26 Simon Fraser Optimize layer updates after scrolling https://bugs.webkit.org/show_bug.cgi?id=102635 Reviewed by Sam Weinig. updateLayerPositionsAfterScroll() previously unconditionally cleared clip rects, and recomputed repaint rects too often. Recomputing both of these can be very expensive, as they involve tree walks up to the root. We can optimize layer updates after document scrolling by only clearing clip rects, and recomputing repaint rects, if we encounter a fixed- or sticky-position element. For overflow scroll, we have to clear clip rects and recompute repaint rects. * page/FrameView.cpp: (WebCore::FrameView::repaintFixedElementsAfterScrolling): Call updateLayerPositionsAfterDocumentScroll(). * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updateLayerPositions): Call clearClipRects() because updateLayerPosition() no longer does. (WebCore::RenderLayer::updateLayerPositionsAfterDocumentScroll): Version of updateLayerPositionsAfterScroll() that is for document scrolls. It has no need to push layers to the geometry map. (WebCore::RenderLayer::updateLayerPositionsAfterOverflowScroll): Pushes layers to the geometry map, and calls updateLayerPositionsAfterScroll() with the IsOverflowScroll flag. (WebCore::RenderLayer::updateLayerPositionsAfterScroll): Set the HasChangedAncestor flag if our location changed, and use that as a hint to clear cached rects. Be more conservative than before about when to clear cached clip rects. (WebCore::RenderLayer::updateLayerPosition): Move responsibility for calling clearClipRects() ouf of this function and into callers. (The one caller outside RenderLayer will be removed via bug 102624). Return a bool indicating whether our position changed. (WebCore::RenderLayer::scrollTo): Call updateLayerPositionsAfterOverflowScroll(). (WebCore::RenderLayer::updateClipRects): Added some #ifdeffed out code that is useful to verify that cached clips are correct; it's too slow to leave enabled in debug builds. * rendering/RenderLayer.h: (WebCore::RenderLayer::setLocation): Change to take a LayoutPoint, rather than separate x and y. 2012-11-26 Simon Fraser Merge r135025 2012-11-12 Simon Fraser Eliminate ancestor tree walk computing outlineBoundsForRepaint() when updating layer positions https://bugs.webkit.org/show_bug.cgi?id=101874 Reviewed by Dave Hyatt. RenderLayer::updateLayerPositions() and updateLayerPositionsAfterScroll() spend a lot of time in computeRepaintRects(), which does two ancestor tree walks, once for clippedOverflowRectForRepaint(), and one for outlineBoundsForRepaint(). Eliminate the ancestor tree walk in outlineBoundsForRepaint() by maintaining a RenderGeometryMap as we traverse the layer tree, and then using it to map the outline bounds to the repaint container. Replace the hokey cached offsetFromRoot now that the RenderGeometryMap can do a better job. The clipped overflow rect cannot be mapped simply, so cannot yet make use of the geometry map. Modify the RenderGeometryMap to support mapping to some repaintContainer ancestor. Add a RenderObject walk that is necessary to detect flipped writing mode blocks. Pass the RenderGeometryMap as an optional parameter to outlineBoundsForRepaint. * page/FrameView.cpp: (WebCore::FrameView::layout): Make a RenderGeometryMap and pass it down to updateLayerPositions(). For partial layouts, we have to push layers between the root and the enclosing layer of the layout subtree. The geometry map used for repainting does not use SnapOffsetForTransforms, so initialize it explicitly with just the UseTransforms flag. (WebCore::FrameView::repaintFixedElementsAfterScrolling): Make a RenderGeometryMap to pass along to updateLayerPositionsAfterScroll(). * rendering/RenderBox.cpp: (WebCore::RenderBox::outlineBoundsForRepaint): Replace the optional cachedOffsetToRepaintContainer parameter with an optional RenderGeometryMap, and it use to map the compute rect to repaintContainer coordinates. * rendering/RenderBox.h: * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::RenderGeometryMap): This now has to store the mapping flags to use, so that its behavior can match that of mapLocalToContainer(). The pertinent flag is the confusingly named SnapOffsetForTransforms. (WebCore::RenderGeometryMap::absolutePoint): Call the new mapToContainer() with a null container. (WebCore::RenderGeometryMap::absoluteRect): Ditto. (WebCore::RenderGeometryMap::mapToContainer): Map to the supplied container, asserting that we found it. Add point- and rect-based mapping methods akin to the old absoluteRect/absolutePoint. (WebCore::canMapViaLayer): We need to test for isRenderFlowThread() here too. (WebCore::RenderGeometryMap::pushMappingsToAncestor): When mapping via layers, ensure that the RenderView is pushed as the first step. * rendering/RenderGeometryMap.h: (RenderGeometryMap): * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updateLayerPositionsAfterLayout): New wrapper for updateLayerPositions() that makes the geometry map. (WebCore::RenderLayer::updateLayerPositionsAfterScroll): New wrapper for updateLayerPositionsAfterScroll that makes the geometry map. (WebCore::RenderLayer::updateLayerPositions): Now takes an optional RenderGeometryMap. Remove the old offsetFromRoot code. Push and pop layers to/from the geometry map. Use the geometry map to get the offsetFromRoot as needed by overflow controls. Pass it to computeRepaintRects(). (WebCore::RenderLayer::computeRepaintRects): Pass the geometry map to outlineBoundsForRepaint(). (WebCore::RenderLayer::updateLayerPositionsAfterScroll): Push and pop to/from the geometry map, and pass it to computeRepaintRects(). (WebCore::RenderLayer::removeOnlyThisLayer): Remove the offsetFromRootBeforeMove computation; this could use a geometry map in future if it is shown to be a bottleneck. * rendering/RenderLayer.h: (WebCore::RenderLayer::canUseConvertToLayerCoords): It was thought that the isComposited() was there because the older cached offsetFromRoot logic was sensitive to compositing, but convertToLayerCoords() is not affected by compositing so this check is not needed, and actually harmful. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::OverlapMap::OverlapMap): The geometry map used for overlap testing should not use SnapOffsetForTransforms, so initialize it explicitly with just the UseTransforms flag. * rendering/RenderObject.h: (WebCore::RenderObject::outlineBoundsForRepaint): * rendering/svg/RenderSVGModelObject.cpp: (WebCore::RenderSVGModelObject::outlineBoundsForRepaint): * rendering/svg/RenderSVGModelObject.h: (RenderSVGModelObject): 2012-11-26 Lucas Forschler Merge r133834 2012-11-07 Tim Horton Repaint issues with -webkit-svg-shadow used on a container https://bugs.webkit.org/show_bug.cgi?id=65643 Reviewed by Simon Fraser. SVG renderer repaint rects are currently expanded only by the shadow of the renderer itself; however, the area they need to repaint can be larger than that, if their parents also have shadows. We need to take into account parent's shadows (respecting transforms, as well). clippedOverflowRectForRepaint already recurses upwards through the render tree, and ends up with a rect in layout coordinates, so we manually apply the shadow at each step (repaintRectInLocalCoordinatesExcludingSVGShadow was added to allow us to get the raw repaint rect without the shadow baked-in). repaintRectInLocalCoordinates now includes shadows from all parents. Also, RenderSVGRoot was clipping repaint rects to the viewport before applying shadows, so offscreen elements with on-screen shadows (applied by the root) would not paint the shadows. We can just swap the order of these things to correct this. Tests: svg/css/parent-shadow-offscreen.svg, svg/css/root-shadow-offscreen.svg, svg/repaint/repaint-webkit-svg-shadow.svg * rendering/RenderObject.cpp: (WebCore::RenderObject::addChild): Mark the child being added as having an SVG shadow if it is being added as a child of an element that does. (WebCore::RenderObject::styleDidChange): Mark the child being added as having an SVG shadow if its new style has a shadow. * rendering/svg/RenderSVGImage.cpp: (WebCore::RenderSVGImage::layout): Cache the repaint rect before intersecting it with the shadow. * rendering/svg/RenderSVGImage.h: (WebCore::RenderSVGImage::repaintRectInLocalCoordinatesExcludingSVGShadow): Return the cached repaint rect for the renderer without the shadow included. * rendering/svg/RenderSVGModelObject.cpp: (WebCore::RenderSVGModelObject::RenderSVGModelObject): Renderers do not have a shadow by default. * rendering/svg/RenderSVGModelObject.h: (WebCore::RenderSVGModelObject::repaintRectInLocalCoordinatesExcludingSVGShadow): Return the cached repaint rect for the renderer without the shadow included. (WebCore::RenderSVGModelObject::hasSVGShadow): Return whether or not the renderer has a shadow. (WebCore::RenderSVGModelObject::setHasSVGShadow): Set whether or not the renderer has a shadow. * rendering/svg/RenderSVGRoot.cpp: (WebCore::RenderSVGRoot::RenderSVGRoot): (WebCore::RenderSVGRoot::computeFloatRectForRepaint): Apply the shadow before clipping to the viewport, so we draw shadows for elements outside the viewport. (WebCore::RenderSVGRoot::updateCachedBoundaries): Cache the repaint rect before intersecting it with the shadow. * rendering/svg/RenderSVGRoot.h: (WebCore::RenderSVGRoot::hasSVGShadow): Return whether or not the renderer has a shadow. (WebCore::RenderSVGRoot::setHasSVGShadow): Set whether or not the renderer has a shadow. (WebCore::RenderSVGRoot::repaintRectInLocalCoordinatesExcludingSVGShadow): Return the cached repaint rect for the renderer without the shadow included. * rendering/svg/RenderSVGShape.cpp: (WebCore::RenderSVGShape::updateRepaintBoundingBox): Cache the repaint rect before intersecting it with the shadow. * rendering/svg/RenderSVGShape.h: (WebCore::RenderSVGShape::repaintRectInLocalCoordinatesExcludingSVGShadow): Return the cached repaint rect for the renderer without the shadow included. * rendering/svg/SVGRenderSupport.cpp: (WebCore::SVGRenderSupport::repaintRectForRendererInLocalCoordinatesExcludingSVGShadow): Return the cached repaint rect for the renderer without the shadow included. (WebCore::SVGRenderSupport::clippedOverflowRectForRepaint): Apply shadows as we walk through our parents, instead of only applying the renderer's own shadow. (WebCore::SVGRenderSupport::rendererHasSVGShadow): Return whether or not the renderer has a shadow. (WebCore::SVGRenderSupport::setRendererHasSVGShadow): Set whether or not the renderer has a shadow. (WebCore::SVGRenderSupport::intersectRepaintRectWithShadows): Walk through the element's parents, adding shadows to the repaint rect as we go, eventually transforming the repaint rect back into local coordinates. (WebCore::SVGRenderSupport::intersectRepaintRectWithResources): Don't add shadows by default, just other resources, so that we can cache repaint rects with and without shadows. * rendering/svg/SVGRenderSupport.h: 2012-11-26 Lucas Forschler Merge r132924 2012-10-30 Dan Bernstein REGRESSION (r121299): OS X Text Replacement forces cursor out of text fields https://bugs.webkit.org/show_bug.cgi?id=100768 Reviewed by Anders Carlsson. r121299 introduced code to restore the paragraph range by saving its length and start offset relative to the document. The latter was obtained by iterating over the range starting at the beginning of the document and ending at the beginning of the paragraph range. However, such a range could not be constructed if the paragraph range was contained in a shadow DOM, since a range must have both its endpoints within the same shadow tree (or not in a shadow tree). Test: platform/mac/editing/spelling/autocorrection-in-textarea.html * editing/Editor.cpp: (WebCore::Editor::markAndReplaceFor): Changed paragraphStartIndex to be relative to the root container of paragraphRange, using the same logic used by checkForDifferentRootContainer() in Range.cpp. 2012-11-18 Simon Fraser Chopin: Don't say there are dirty overlay scrollbars when they are clipped out (102609) Merge r135064 2012-11-17 Simon Fraser Don't say there are dirty overlay scrollbars when they are clipped out https://bugs.webkit.org/show_bug.cgi?id=102609 Reviewed by Brady Eidson. Painting overlay scrollbars involves a second painting pass over the entire RenderLayer subtree for a compositing layer, which can be very expensive. Avoid this when possible by detecting when overflow controls are not in the damage rect. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::rectForHorizontalScrollbar): Compute a local rect for the horizontal scrollbar. (WebCore::RenderLayer::rectForVerticalScrollbar): Compute a local rect for the vertical scrollbar. (WebCore::RenderLayer::positionOverflowControls): Use rectForHorizontalScrollbar() and rectForVerticalScrollbar(). (WebCore::RenderLayer::overflowControlsIntersectRect): Return true if any of the present overflow controls intersect the given local rect. (WebCore::RenderLayer::paintOverflowControls): Bail if the damage rect doesn't intersect any of the overflow controls. * rendering/RenderLayer.h: (RenderLayer): 2012-11-18 Simon Fraser Simplify bounds computation for the RenderView's layer (102597) Merge r135059 2012-11-17 Simon Fraser Simplify bounds computation for the RenderView's layer https://bugs.webkit.org/show_bug.cgi?id=102597 Reviewed by Anders Carlsson. Computing the bounds of the main layer (that of the RenderView) used to do a full RenderLayer walk, taking the union of the bounds of all the sublayers, which is very expensive on large pages. For the RenderView we can avoid that entirely and just use the RenderView's document rect. Since page scaling happens as a transform on this layer, we want the unscaled document rect. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::calculateLayerBounds): 2012-11-18 Simon Fraser Fix overlay scrollbar painting in compositing layers (102442) Merge r135029 2012-11-16 Simon Fraser Fix overlay scrollbar painting in compositing layers https://bugs.webkit.org/show_bug.cgi?id=102442 Reviewed by Beth Dakin. There were two issues with overlay scrollbar painting in compositing layers. First, we'd only ever call setContainsDirtyOverlayScrollbars() on the RenderView's layer, even when encountering an overlay scrollbar in some descendant compositing layer. This meant that we'd never run the paintOverlayScrollbars() code for those child compositing layers, so sometimes scrollbars were missing there. Even after fixing that, we would fail to render scrollbars that were not in the composited RenderLayer itself. This happened because we called into RenderLayer::paintOverlayScrollbars(), which called paintLayer() with flags that only said to paint the overlay scrollbars but not any descendants, so this paint path would not walk child RenderLayers. Also remove the containsScrollableAreaWithOverlayScrollbars() flag on ScrollView which is no longer used. * platform/ScrollView.cpp: (WebCore::ScrollView::ScrollView): Remove containsScrollableAreaWithOverlayScrollbars(). (WebCore::ScrollView::paint): Remove setting of m_containsScrollableAreaWithOverlayScrollbars. * platform/ScrollView.h: * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintOverflowControls): Call setContainsDirtyOverlayScrollbars() on the compositing ancestor or the root. Remove call to setContainsScrollableAreaWithOverlayScrollbars(). (WebCore::RenderLayer::paintOverlayScrollbars): When painting overlay scrollbars, no need to say we have transparency, and no need to use temporary clip rects. (WebCore::RenderLayer::paintLayer): The PaintLayerPaintingOverlayScrollbars check here was only needed because the compositing entrypoint to painting overlay scrollbars went via paintLayer(), which isn't normally used as a composited painting entry point. Now that we no longer call that, we don't need this special check. * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::paintIntoLayer): Jump into overlay scrollbar painting via paintLayerContents(), not paintOverlayScrollbars(), since the latter does not traverse sublayers. 2012-11-18 Simon Fraser Prerequisite for Fix overlay scrollbar painting in compositing layers (102442) Merge r127943 2012-09-07 Simon Fraser box-shadow causes overlay scrollbars to be in the wrong position when element is composited https://bugs.webkit.org/show_bug.cgi?id=85647 Reviewed by James Robinson. The code that positioned the GraphicsLayers for scrollbars failed to take into account any offset between the origin of the compositing layer, and the renderer. This caused scrollbar layers to be misplaced or hidden on layers with, for example, box-shadows. Also moved the code that positions the scrollbar layers into RendderLayerBacking, since this is where all the rest of the GraphicsLayer-positioning code lives. Renamed an "offsetFromLayer" param to "offsetFromRoot" which is more accurate. Manual test, since overlay scrollbars are not enabled in DRT/WTR: ManualTests/scrollbars/scrollbars-in-composited-layers.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::positionOverflowControls): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::positionOverflowControlsLayers): * rendering/RenderLayerBacking.h: (RenderLayerBacking): 2012-11-16 Andy Estes Fix the Mountain Lion build after r135007. * bindings/js/JSDesktopNotificationsCustom.cpp: (WebCore::JSNotificationCenter::requestPermission): 2012-11-16 Lucas Forschler Merge r131779 2012-10-18 Jer Noble Add diagnostic logging to track per-page media engine usage. https://bugs.webkit.org/show_bug.cgi?id=99615 Reviewed by Eric Carlson. Add diagnostic logging triggered only once-per-page and once-per-page-per-engine. * html/HTMLMediaElement.cpp: (WebCore::logMediaLoadRequest): Encapsulate diagnostic logging into single static method. (WebCore::HTMLMediaElement::mediaLoadingFailed): Call logMediaLoadRequest. (WebCore::HTMLMediaElement::setReadyState): Ditto. * loader/FrameLoader.cpp: (WebCore::FrameLoader::dispatchDidCommitLoad): Reset the set of seen media engines. Add new methods to Page to track per-page media engine diagnostic info, similar to plugin diagnostic info. * page/Page.cpp: (WebCore::Page::hasSeenAnyMediaEngine): (WebCore::Page::hasSeenMediaEngine): (WebCore::Page::sawMediaEngine): (WebCore::Page::resetSeenMediaEngines): * page/Page.h: Add new static logging key definitions: * page/DiagnosticLoggingKeys.cpp: (WebCore::DiagnosticLoggingKeys::pageContainsMediaEngineKey): (WebCore::DiagnosticLoggingKeys::pageContainsAtLeastOneMediaEngineKey): * page/DiagnosticLoggingKeys.h: 2012-11-16 Lucas Forschler Merge r131280 2012-10-14 Jon Lee Allow notification origin permission request when no js callback is provided https://bugs.webkit.org/show_bug.cgi?id=63615 Reviewed by Sam Weinig. Instead of throwing a type error when no callback is provided, we pass a null callback. Test: http/tests/notifications/legacy/request-no-callback.html * bindings/js/JSDesktopNotificationsCustom.cpp: (WebCore::JSNotificationCenter::requestPermission): 2012-11-16 Lucas Forschler Merge r130565 2012-10-05 Tim Horton [cg] GraphicsContextCG should ask CG whether the shadow offset workaround is required https://bugs.webkit.org/show_bug.cgi?id=98565 Reviewed by Simon Fraser. On Mountain Lion and above, CG can tell us whether we need to work around incorrect shadow offsets. Prior to Mountain Lion, we should assume we need to apply the workaround. No new tests, as this requires an obscure configuration to test. * WebCore.exp.in: * platform/graphics/cg/GraphicsContextCG.cpp: (WebCore::applyShadowOffsetWorkaroundIfNeeded): (WebCore::GraphicsContext::setPlatformShadow): * platform/mac/WebCoreSystemInterface.h: Add wkCGContextDrawsWithCorrectShadowOffsets. * platform/mac/WebCoreSystemInterface.mm: Add wkCGContextDrawsWithCorrectShadowOffsets. 2012-11-16 Lucas Forschler Merge r134903 2012-11-15 Jer Noble Crash at WebCore::PluginData::pluginFileForMimeType const + 38 https://bugs.webkit.org/show_bug.cgi?id=102454 Reviewed by Dan Bernstein. NULL-check the return value of Page::pluginData(). * loader/SubframeLoader.cpp: (WebCore::logPluginRequest): 2012-11-15 Andy Estes Merge r130266. 2012-10-03 Dominic Mazzoni AX: Heap-use-after-free when deleting a ContainerNode with an AX object https://bugs.webkit.org/show_bug.cgi?id=98073 Reviewed by Hajime Morita. Calls axObjectCache()->remove(this) in ~ContainerNode so that the AX tree doesn't try to access the container node while walking up the parent chain from one of the container node's children. Test: accessibility/container-node-delete-causes-crash.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::~ContainerNode): * dom/Node.cpp: (WebCore::Node::~Node): * dom/Node.h: (WebCore::Node::document): (WebCore::Node::documentInternal): 2012-11-15 Andy Estes Merge r116629 and r127534. 2012-09-04 Sergey Glazunov Frame element doesn't always unload its child frame. https://bugs.webkit.org/show_bug.cgi?id=94717 Reviewed by Hajime Morita. It's possible for a frame element that has been removed from the document to retain an active child frame. This inconsistent state may become a source of security vulnerabilities. The patch adds a global HashSet to store the nodes currently processed by ChildFrameDisconnector. Insertion into these nodes' subtrees is not allowed until the processing is complete. Also, the ChildFrameDisconnector call in removeChild(ren) is now immediately followed by the actual removal. Test: fast/frames/out-of-document-iframe-has-child-frame.html * dom/ContainerNode.cpp: (WebCore::willRemoveChildren): Move the ChildFrameDisconnector call out of a loop. (WebCore::ContainerNode::removeChild): Rearrange some event firing code. (WebCore::ContainerNode::removeChildren): Ditto. * dom/ContainerNodeAlgorithms.cpp: (WebCore::ChildFrameDisconnector::collectDescendant): Pass a new parameter to collectDescendant(Node*). * dom/ContainerNodeAlgorithms.h: (WebCore::ChildFrameDisconnector::ChildFrameDisconnector): (ChildFrameDisconnector): Maintain a list of nodes that have an active ChildFrameDisconnector. (WebCore::ChildFrameDisconnector::~ChildFrameDisconnector): (WebCore::ChildFrameDisconnector::rootNodes): (WebCore::ChildFrameDisconnector::collectDescendant): Add ShouldIncludeRoot parameter. (WebCore::ChildFrameDisconnector::nodeHasDisconnector): (WebCore): * dom/Node.cpp: (WebCore::checkAcceptChild): Reject a parent node if it or one of its parents has an active ChildFrameDisconnector. * html/HTMLFrameElementBase.cpp: (WebCore::HTMLFrameElementBase::didNotifySubtreeInsertions): Check if an element is still in the document. 2012-05-10 MORITA Hajime Remove support for Node::willRemove() https://bugs.webkit.org/show_bug.cgi?id=55209 Reviewed by Ryosuke Niwa. This change de-virtualizes Node::willRemove(), gains 5% speedup on Dromaeo dom-modify. Originally there were 5 willRemove() overrides: - Element - HTMLStyleElement - HTMLSourceElement - HTMLTrackElement - HTMLFrameOwnerElement For first 4 items, this change moves their implementations to Node::removedFrom() overrides. Then HTMLFrameOwnerElement is the only class which needs the notification. Because it emits the "unload" event, it needs some notification _before_ its removal. To handle that, this change introduces ChildFrameDisconnector which collects corresponding decendant elements and disconnect their content frame. Even though this approach doesn't kill pre-removal tree traversal completely, it's a bit more efficient due to the de-virtualization. No new tests. Covered by existing test. * dom/ContainerNode.cpp: (WebCore::willRemoveChild): Replaced willRemove() call with ChildFrameDisconnector. (WebCore::willRemoveChildren): Ditto. (WebCore::ContainerNode::disconnectDescendantFrames): Added. Used from FrameLoader to replace Document::willRemove() call. (WebCore): * dom/ContainerNode.h: (ContainerNode): * dom/ContainerNodeAlgorithms.cpp: (WebCore::ChildFrameDisconnector::collectDescendant): (WebCore): (WebCore::ChildFrameDisconnector::Target::disconnect): * dom/ContainerNodeAlgorithms.h: (ChildFrameDisconnector): (Target): (WebCore::ChildFrameDisconnector::Target::Target): (WebCore::ChildFrameDisconnector::Target::isValid): (WebCore): (WebCore::ChildFrameDisconnector::ChildFrameDisconnector): (WebCore::ChildFrameDisconnector::collectDescendant): (WebCore::ChildFrameDisconnector::disconnect): * dom/Element.cpp: (WebCore::Element::removedFrom): * dom/Element.h: * dom/ElementShadow.cpp: * dom/ElementShadow.h: (ElementShadow): * dom/Node.cpp: * dom/Node.h: Added IsFrameOwnerElement flag to de-virtualize IsFrameOwnerElement(). (WebCore::Node::isFrameOwnerElement): De-virtualized. (Node): * html/HTMLElement.h: (HTMLElement): (WebCore::HTMLElement::HTMLElement): * html/HTMLFrameOwnerElement.cpp: (WebCore::HTMLFrameOwnerElement::HTMLFrameOwnerElement): (WebCore::HTMLFrameOwnerElement::disconnectContentFrame): Extracted from original willRemove(). * html/HTMLFrameOwnerElement.h: (HTMLFrameOwnerElement): (WebCore::toFrameOwnerElement): (WebCore): * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::sourceWasRemoved): Renamed from sourceWillBeRemoved(), dealing with the timing change. * html/HTMLMediaElement.h: (HTMLMediaElement): (WebCore::isMediaElement): (WebCore): (WebCore::toMediaElement): * html/HTMLSourceElement.cpp: (WebCore::HTMLSourceElement::removedFrom): Moved some code from willRemove(). * html/HTMLSourceElement.h: (HTMLSourceElement): * html/HTMLStyleElement.cpp: (WebCore::HTMLStyleElement::removedFrom): (WebCore): * html/HTMLStyleElement.h: (HTMLStyleElement): * html/HTMLTrackElement.cpp: (WebCore::HTMLTrackElement::removedFrom): Moved some code from willRemove(). * html/HTMLTrackElement.h: (HTMLTrackElement): * loader/FrameLoader.cpp: (WebCore::FrameLoader::clear): 2012-11-15 Lucas Forschler Merge r134083 2012-11-09 Jer Noble Plugin diagnostic logging should send plugin file basename instead of MIME type. https://bugs.webkit.org/show_bug.cgi?id=101679 Reviewed by Eric Carlson. Log the basename of the plugin file rather than the mime type so as to more accurately log which plugin was used to handle the request. * loader/SubframeLoader.cpp: (WebCore::logPluginRequest): Log the plugin 'file' field, if present. * plugins/PluginData.cpp: (WebCore::PluginData::pluginInfoForMimeType): Factored out from pluginNameForMimeType. (WebCore::PluginData::pluginNameForMimeType): Use pluginInfoForMimeType to retrieve name field. (WebCore::PluginData::pluginFileForMimeType): Use pluginInfoForMimeType to retrieve file field. * plugins/PluginData.h: 2012-11-15 Lucas Forschler Merge r130449 2012-10-04 Nate Chapin Crash in EventHandler::mouseMoved(). https://bugs.webkit.org/show_bug.cgi?id=98460 Reviewed by Abhishek Arya. No new tests, this fixes fast/events/mouse-moved-remove-frame-crash.html. * page/EventHandler.cpp: (WebCore::EventHandler::mouseMoved): 2012-11-14 Simon Fraser Scrolling some versions of the facebook page is very slow Merge r134737 2012-11-14 Simon Fraser Don't use temporary clip rects when hit testing https://bugs.webkit.org/show_bug.cgi?id=102329 Reviewed by Beth Dakin. We now cache clip rects separately for painting, hit testing etc. Hit testing clip rects are always shrunk to exclude scrollbars (so that hit testing on the scrollbars works), so we no longer every need to use temporary clip rects during hit testing. Added an assertion that the scrollbar relevancy when we computed the clip rects is the same as that when using them. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::hitTestLayer): (WebCore::RenderLayer::updateClipRects): * rendering/RenderLayer.h: (WebCore::ClipRectsCache::ClipRectsCache): (ClipRectsCache): 2012-11-14 Timothy Hatcher Merge r134100 2012-10-28 Timothy Hatcher Make -webkit-canvas in CSS use the full backing store instead of always 1x when rendering. https://bugs.webkit.org/show_bug.cgi?id=100611 Reviewed by Dean Jackson. Test: fast/canvas/canvas-as-image-hidpi.html * html/HTMLCanvasElement.cpp: (WebCore::HTMLCanvasElement::makePresentationCopy): Pass Unscaled to copyImage. (WebCore::HTMLCanvasElement::copiedImage): Ditto. * platform/graphics/ImageBuffer.h: * platform/graphics/cg/ImageBufferCG.cpp: (WebCore::ImageBuffer::copyImage): Added Scale parameter and use copyNativeImage for Unscaled. * platform/graphics/cairo/ImageBufferCairo.cpp: (WebCore::ImageBuffer::copyImage): Added unnamed ScaleBehavior parameter. * platform/graphics/qt/ImageBufferQt.cpp: (WebCore::ImageBuffer::copyImage): Ditto. * platform/graphics/skia/ImageBufferSkia.cpp: (WebCore::ImageBuffer::copyImage): Ditto. * platform/graphics/wince/ImageBufferWinCE.cpp: (WebCore::ImageBuffer::copyImage): Ditto. * platform/graphics/wx/ImageBufferWx.cpp: (WebCore::ImageBuffer::copyImage): Ditto. 2012-11-14 Timothy Hatcher Merge r134099 2012-10-28 Timothy Hatcher Reset the canvas backing store pixel ratio when the buffer resizes. The backing store was not being recreated using the current page pixel ratio when a resize occurred. https://bugs.webkit.org/show_bug.cgi?id=100608 Reviewed by Darin Adler. Test: fast/canvas/canvas-resize-reset-pixelRatio.html * html/HTMLCanvasElement.cpp: (WebCore::HTMLCanvasElement::HTMLCanvasElement): Use targetDeviceScaleFactor. (WebCore::HTMLCanvasElement::reset): Do a clear only if the pixel ratios also match. Store the new pixel ratio in m_deviceScaleFactor. (WebCore::HTMLCanvasElement::targetDeviceScaleFactor): Added. * html/HTMLCanvasElement.h: (WebCore::HTMLCanvasElement::setSize): Return early only if the sizes and pixel ratios match. 2012-11-14 Simon Fraser Don't pass a paintingRoot when painting from RenderLayerBacking (102256) Merge r134642 2012-11-14 Simon Fraser Don't pass a paintingRoot when painting from RenderLayerBacking https://bugs.webkit.org/show_bug.cgi?id=102256 Reviewed by David Hyatt. The 'paintingRoot' parameter to the RenderLayer paint functions is used when painting just a subtree (e.g. when painting dragged selections). There is no need to pass it when a RenderLayerBacking paints its contents or overlay scrollbars. Passing it requires an expensive isDescendant() check, so passing null is more efficient. * rendering/RenderLayer.h: (WebCore::RenderLayer::LayerPaintingInfo::LayerPaintingInfo): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::paintIntoLayer): (WebCore::RenderLayerBacking::paintContents): * rendering/RenderLayerBacking.h: (RenderLayerBacking): 2012-11-13 Simon Fraser Chopin: Avoid calling calculateLayerBounds() and convertToLayerCoords() more than once per layer paint (102031) Merge r134356 2012-11-12 Simon Fraser Avoid calling calculateLayerBounds() and convertToLayerCoords() more than once per layer paint https://bugs.webkit.org/show_bug.cgi?id=102031 Reviewed by Beth Dakin. RenderLayer::paintLayerContents() and callees could end up calling convertToLayerCoords() and calculateLayerBounds() multiple times for painting a single layer. Keep track of whether we've computed the root-relative bounds and do it on demand. Compute the offset relative to rootLayer once, and pass it around as an optional parameter to functions that need it. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintLayerContents): (WebCore::RenderLayer::hitTestLayer): (WebCore::RenderLayer::calculateRects): (WebCore::RenderLayer::intersectsDamageRect): (WebCore::RenderLayer::boundingBox): (WebCore::RenderLayer::calculateLayerBounds): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::calculateCompositedBounds): 2012-11-13 Simon Fraser Prerequisite for . Merge r134355 2012-11-12 Simon Fraser Change calculateLayerBounds() from a static function to a member function https://bugs.webkit.org/show_bug.cgi?id=102022 Reviewed by Beth Dakin. calculateLayerBounds() has grown into a substantial function after starting live as a little utility function, so make it a member function of RenderLayer, and adjust callers accordingly. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::setFilterBackendNeedsRepaintingInRect): (WebCore::RenderLayer::paintLayerContents): (WebCore::RenderLayer::calculateLayerBounds): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::calculateCompositedBounds): 2012-11-13 Simon Fraser Merge r134330 2012-11-12 Simon Fraser Fix filter dirty rect regression from r134311 https://bugs.webkit.org/show_bug.cgi?id=102002 Reviewed by Beth Dakin. When rendering with filters, the code can inflate the root-relative paintDirtyRect in RenderLayer::paintLayerContents(), and my cleanup broke this behavior. Fix by making a local copy of LayerPaintingInfo, updating its paintDirtyRect, and using it for the rest of the function. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintLayerContents): 2012-11-13 Simon Fraser Reduce the crazy number of parameters to RenderLayer painting member functions (101895) Merge r134311 2012-11-12 Simon Fraser Reduce the crazy number of parameters to RenderLayer painting member functions https://bugs.webkit.org/show_bug.cgi?id=101895 Reviewed by Beth Dakin. The various RenderLayer::paintLayer* functions took a lot of arguments, most of which were passed down directly to descendants. Gather these arguments into a LayerPaintingInfo struct. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paint): Create a LayerPaintingInfo struct to pass to descendant paint calls. (WebCore::RenderLayer::paintOverlayScrollbars): Ditto. (WebCore::RenderLayer::paintLayer): When painting transformed layers, we make a new LayerPaintingInfo because the root layer is shifted. (WebCore::RenderLayer::paintLayerContentsAndReflection): (WebCore::RenderLayer::paintLayerContents): (WebCore::RenderLayer::paintList): (WebCore::RenderLayer::paintPaginatedChildLayer): (WebCore::RenderLayer::paintChildLayerIntoColumns): Create a new LayerPaintingInfo struct for column painting. * rendering/RenderLayer.h: (WebCore::RenderLayer::LayerPaintingInfo::LayerPaintingInfo): (LayerPaintingInfo): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::paintIntoLayer): Build a LayerPaintingInfo to enter layer painting. * rendering/RenderReplica.cpp: (WebCore::RenderReplica::paint): Ditto. 2012-11-13 Simon Fraser Save one call to containerForRepaint() when updating layer positions (101856) Merge r134174 2012-11-10 Simon Fraser Save one call to containerForRepaint() when updating layer positions https://bugs.webkit.org/show_bug.cgi?id=101856 Reviewed by Dan Bernstein. RenderLayer::updateLayerPositions() has already computed the repaint container, but calls computeRepaintRects() which computes it again. Computing the repaint container involves a walk back up the layer tree, so calling it during a tree traversal is costly. Fix by passing the repaint container down into computeRepaintRects(). * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updateLayerPositions): (WebCore::RenderLayer::computeRepaintRects): (WebCore::RenderLayer::computeRepaintRectsIncludingDescendants): (WebCore::RenderLayer::updateLayerPositionsAfterScroll): (WebCore::RenderLayer::setHasVisibleContent): * rendering/RenderLayer.h: (RenderLayer): 2012-11-13 Simon Fraser Cache absolute clip rects on RenderLayer for compositing overlap testing (87212) Merge r119458 2012-06-04 Simon Fraser Leaking ClipRects https://bugs.webkit.org/show_bug.cgi?id=88282 Reviewed by Dan Bernstein. In r118562 I made the ClipRectsCache use RefPtr. However, ClipRects was initialized with m_refCnt=0, not 1 as adoptRef() and friends expect. Also, there was a manual ref() in RenderLayer::updateClipRects() which this patch removes. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updateClipRects): * rendering/RenderLayer.h: (WebCore::ClipRects::ClipRects): 2012-11-13 Simon Fraser Cache absolute clip rects on RenderLayer for compositing overlap testing (87212) Merge r118612 2012-05-26 Simon Fraser Clip rects assertion when hovering div with transform https://bugs.webkit.org/show_bug.cgi?id=87580 Reviewed by Eric Seidel. Hit testing used to use temporary clip rects in composited documents, until r118562. Now that we cache clip rects for hit testing, we need to clear the cache on descendant layers when a layer gains or loses a transform. Test: fast/layers/clip-rects-assertion.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updateTransform): 2012-11-13 Simon Fraser Cache absolute clip rects on RenderLayer for compositing overlap testing (87212) Merge r119458. 2012-05-25 Simon Fraser Cache absolute clip rects on RenderLayer for compositing overlap testing https://bugs.webkit.org/show_bug.cgi?id=87212 Reviewed by Dave Hyatt. Enhance the cache of ClipRects on RenderLayers to store three different types of ClipRects, rather than just one. We need to compute clip rects relative to different layers for different purposes. For painting, we compute relative to the compositing layer which is acting as a painting root. For hit testing, we compute relative to the root, except for transformed layers. For composting overlap testing, we compute relative to the root ("absolute"). At other times, we do one-off computation which we never want to cache ("temporary clip rects"). This change allows us to cache rects for hit testing, and for compositing overlap testing. This has huge performance benefits on some pages (bug 84410). This change also makes ClipRects not arena-allocated, so we can use RefPtr. No testable behavior change. * rendering/RenderBoxModelObject.cpp: (WebCore::RenderBoxModelObject::willBeDestroyed): No need for the explicit clipRects teardown, since clipRects don't need a live RenderObject for arena-based destruction. * rendering/RenderLayer.cpp: Remove arena-related new and delete. (WebCore::RenderLayer::RenderLayer): No need to explicitly initialize m_clipRects, since it's an OwnPtr now. (WebCore::RenderLayer::~RenderLayer): No explicit clipRect teardown required. (WebCore::RenderLayer::clippingRootForPainting): Renamed to make its purpose more obvious. (WebCore::RenderLayer::paintLayer): Use the TemporaryClipRects type when necessary. (WebCore::RenderLayer::paintLayerContents): Ditto (WebCore::RenderLayer::hitTestLayer): No longer need to use temporary clipRects when hit testing since we cache clip rects for hit testing. (WebCore::RenderLayer::updateClipRects): Take a ClipRectsType and pass it through. (WebCore::RenderLayer::calculateClipRects): Ditto (WebCore::RenderLayer::parentClipRects): Ditto (WebCore::RenderLayer::backgroundClipRect): Ditto (WebCore::RenderLayer::calculateRects): Take ClipRectsType, which obviates temporaryClipRects. (WebCore::RenderLayer::childrenClipRect): Use clippingRootForPainting(). (WebCore::RenderLayer::selfClipRect): Ditto (WebCore::RenderLayer::localClipRect): Ditto (WebCore::RenderLayer::clearClipRectsIncludingDescendants): Take a type of clip rect to clear (include all). Allows us to just clear painting clip rects. (WebCore::RenderLayer::clearClipRects): * rendering/RenderLayer.h: (WebCore::ClipRects::create): We don't use RefCounted<> in order to use a bit in the refCount for a flag. Add create() method. (WebCore::ClipRects::deref): No longer arena-allocated. (WebCore::ClipRectsCache::ClipRectsCache): Struct that holds a small array of the 3 types of clipRects (and, in debug, the layer relative to which they were computed). (WebCore::RenderLayer::clipRects): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::updateCompositedBounds): Use AbsoluteClipRects; rootLayer is always the RenderView's layer here. (WebCore::RenderLayerBacking::updateGraphicsLayerGeometry): Use TemporaryClipRects. (WebCore::RenderLayerBacking::setRequiresOwnBackingStore): When this variable changes, we need to invalidate painting clipRects, since it affects the ancestor relative to which those rects are computed. * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateBacking): When the composited state of a layer changes, we have to clear all descendant clip rects, since this can affect the layers relative to which clip rects are computed. (WebCore::RenderLayerCompositor::addToOverlapMap): Use AbsoluteClipRects. (WebCore::RenderLayerCompositor::computeCompositingRequirements): No need to call updateLayerPosition(), since that should have always happened after layout. That call cleared clip rects, so removing it is very beneficial. (WebCore::RenderLayerCompositor::clippedByAncestor): Use TemporaryClipRects. * rendering/RenderTreeAsText.cpp: (WebCore::writeLayers): Use TemporaryClipRects. 2012-11-13 Simon Fraser Terrible performance on http://alliances.commandandconquer.com/ and http://www.lordofultima.com/ and App Store (84410) Merge r118567, r118617, r118957, r119172, r121124, r121130, r121306, r121446, r122376, r122653 (partial), r122802 (partial), r133248 2012-11-01 Tien-Ren Chen Fix assertion failure in RenderGeometryMap::absoluteRect when frame scale != 1.0 https://bugs.webkit.org/show_bug.cgi?id=100912 Reviewed by Simon Fraser. Frame scale will add transformation to RenderView, so fixed position doesn't get propagated up to the viewport by RenderGeometryMap. This is handled correctly in RenderView::mapLocalToContainer, causing the assertion to fail. This patch corrects RenderGeometryMap::mapToAbsolute to handle the RenderView transformation case. A layout test is added to catch this issue. The test will crash debug build without this patch. Test: compositing/geometry/fixed-position-composited-page-scale-scroll.html * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::mapToAbsolute): 2012-07-16 Kiran Muppala REGRESSION: RenderInline::absoluteQuads produces incorrect results for fixed position. https://bugs.webkit.org/show_bug.cgi?id=91451 Reviewed by Simon Fraser. RenderInline::absoluteQuads relies on copies of RenderGeometryMap, created indirectly by passing AbsoluteQuadsGeneratorContext object by value. These copies are unsafe because the individual transform steps within the geometry map include a owned poitner to their respective transform. Modify the callee methods to take context by reference and disable copy constructor for RenderGeometryMap. Test: fast/inline/inline-fixed-position-boundingbox.html * rendering/RenderGeometryMap.h: (WebCore::RenderGeometryMapStep::RenderGeometryMapStep): Add missing m_offset to copy constructor initialization list. (RenderGeometryMap): Disable copy constructor. * rendering/RenderInline.cpp: Pass context object by reference. (WebCore::RenderInline::generateLineBoxRects): (WebCore::RenderInline::generateCulledLineBoxRects): (WebCore::RenderInline::absoluteRects): (WebCore::RenderInline::absoluteQuads): (WebCore::RenderInline::linesBoundingBox): (WebCore::RenderInline::culledInlineVisualOverflowBoundingBox): (WebCore::RenderInline::addFocusRingRects): * rendering/RenderInline.h: (RenderInline::generateLineBoxRects): Update method declarations to show pass by reference context parameter. (RenderInline::generateCulledLineBoxRects): Ditto. 2012-07-13 Kiran Muppala REGRESSION: RenderInline boundingBox ignores relative position offset https://bugs.webkit.org/show_bug.cgi?id=91168 Reviewed by Simon Fraser. RenderGeometryMap, used for caching the transform to the view, expects the first mapping pushed, to be that of the view itself. RenderInline was instead pushing it's own offset first. Besides the offset of the view itself was not being pushed. Relaxed the RenderGeometryMap restriction that the first pushed step should be of the view. It is sufficient that the view's mapping is pushed in the first call to pushMappingsToAncestor. Modified RenderInline to push the offset of the view also to the geometry map. Test: fast/inline/inline-relative-offset-boundingbox.html * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::pushMappingsToAncestor): Add assertion to check if mapping to view was pushed in first invocation. (WebCore::RenderGeometryMap::pushView): Correct assertion that checks if the view's mapping is the first one to be applied. (WebCore::RenderGeometryMap::stepInserted): Use isRenderView to check if a mapping step belongs to a view instead of using mapping size. (WebCore::RenderGeometryMap::stepRemoved): Ditto. * rendering/RenderInline.cpp: (WebCore::(anonymous namespace)::AbsoluteQuadsGeneratorContext::AbsoluteQuadsGeneratorContext): Push mappings all the way up to and including the view. 2012-07-10 Simon Fraser Assertion ASSERTION FAILED: enclosingIntRect(rendererMappedResult) == enclosingIntRect(FloatQuad(result).boundingBox()) when compositing in paginated mode https://bugs.webkit.org/show_bug.cgi?id=90919 Reviewed by Antti Koivisto. r121124 added a fast path for geometry mapping that goes via layers when possible. However, this broke paginated pages, which put the root (RenderView) layer into column mode, because it failed to check for columns on the ancestor layer. Rather than make a risky change to convertToLayerCoords(), add a local function canMapViaLayer(), which is like RenderLayer::canUseConvertToLayerCoords(), but doesn't check for compositing (compositing itself is not a reason to avoid convertToLayerCoords). Call canMapViaLayer() with the ancestorLayer to check whether the ancestor has columns, which fixes the bug. Test: compositing/columns/geometry-map-paginated-assert.html * rendering/RenderGeometryMap.cpp: (WebCore::canMapViaLayer): (WebCore::RenderGeometryMap::pushMappingsToAncestor): 2012-06-28 Antti Koivisto Don't malloc RenderGeometryMap steps individually https://bugs.webkit.org/show_bug.cgi?id=90074 Reviewed by Simon Fraser. Mallocs and frees for steps under RenderGeometryMap::pus/popMappingsToAncestor can total ~2% of the profile when animating transforms. * rendering/RenderGeometryMap.cpp: (WebCore): (WebCore::RenderGeometryMap::absolutePoint): (WebCore::RenderGeometryMap::absoluteRect): (WebCore::RenderGeometryMap::mapToAbsolute): (WebCore::RenderGeometryMap::push): (WebCore::RenderGeometryMap::pushView): (WebCore::RenderGeometryMap::popMappingsToAncestor): * rendering/RenderGeometryMap.h: (WebCore): (WebCore::RenderGeometryMapStep::RenderGeometryMapStep): Move to header. (RenderGeometryMapStep): (RenderGeometryMap): Make the step vector hold RenderGeometryMapSteps instead of RenderGeometryMapStep*'s. (WTF): Give RenderGeometryMapSteps SimpleClassVectorTraits. This is needed for dealing with OwnPtr in the struct (and makes it faster too). The type is simple enought to move by memcpy. 2012-06-26 Simon Fraser Optimize mappings of simple transforms in RenderGeometryMap https://bugs.webkit.org/show_bug.cgi?id=90034 Reviewed by Dean Jackson. For transforms that are identity or simple translations, don't fall off the fast path in RenderGeometryMap; we can just treat them as offsets. Improves performance on pages with lots of translateZ(0) elements. Remove RenderGeometryMapStep::mapPoint() and mapQuad(), which were unused. No new tests; optimization only, and tested by assertions. * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::push): 2012-06-24 Antti Koivisto REGRESSION(r121124): LayoutTests/fast/block/inline-children-root-linebox-crash.html asserts https://bugs.webkit.org/show_bug.cgi?id=89844 Reviewed by Dan Bernstein. We need to check for the flipped writing mode and take the slow path if it is used. * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::pushMappingsToAncestor): 2012-06-24 Antti Koivisto Optimize RenderGeometryMap mappings gathering https://bugs.webkit.org/show_bug.cgi?id=89828 Reviewed by Simon Fraser. RenderGeometryMap currently gathers mappings by climbing the rendering tree. This is slow and can produce large number of mapping steps. In the common case we already have the child layer coordinates available in the layer tree and we can just use that. The combination of faster mappings gathering and fewer number of applying steps reduces time spent under RenderLayerCompositor::computeCompositingRequirements to less than half when scrolling the mobile version of twitter.com. * rendering/RenderGeometryMap.cpp: (WebCore): (WebCore::RenderGeometryMap::pushMappingsToAncestor): Use pre-computed mapping from the layer tree when possible. (WebCore::RenderGeometryMap::popMappingsToAncestor): * rendering/RenderGeometryMap.h: Add some inline capacity. (WebCore): (RenderGeometryMap): * rendering/RenderLayer.h: (WebCore::RenderLayer::canUseConvertToLayerCoords): (RenderLayer): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::addToOverlapMapRecursive): (WebCore::RenderLayerCompositor::computeCompositingRequirements): 2012-05-31 Simon Fraser RenderLayerCompositor cleanup: make RenderGeometryMap part of the OverlapMap https://bugs.webkit.org/show_bug.cgi?id=88021 Reviewed by James Robinson. We only ever use the RenderGeometryMap when we have an OverlapMap, so make it a member of the OverlapMap. No behavior change. * rendering/RenderLayerCompositor.cpp: (RenderLayerCompositor::OverlapMap): (WebCore::RenderLayerCompositor::OverlapMap::geometryMap): (WebCore::RenderLayerCompositor::updateCompositingLayers): (WebCore::RenderLayerCompositor::addToOverlapMap): (WebCore::RenderLayerCompositor::addToOverlapMapRecursive): (WebCore::RenderLayerCompositor::computeCompositingRequirements): * rendering/RenderLayerCompositor.h: (WebCore): (RenderLayerCompositor): 2012-05-29 Adrienne Walker Transformed fixed position layers have an incorrect overlap map entry https://bugs.webkit.org/show_bug.cgi?id=64201 Reviewed by Darin Adler. Previously, layers that both had a transform and were fixed position were not considered as being fixed position in RenderGeometryMap or in RenderBox::mapLocalToContainer (although this case is not incorrect in the case of painting, so an external caller likely adjusts for this). Tests: compositing/layer-creation/fixed-position-and-transform.html compositing/layer-creation/fixed-position-under-transform.html * rendering/RenderBox.cpp: (WebCore::RenderBox::mapLocalToContainer): * rendering/RenderGeometryMap.cpp: (WebCore::RenderGeometryMap::mapToAbsolute): 2012-05-26 Simon Fraser fast/block/inline-children-root-linebox-crash.html asserts after r118567 https://bugs.webkit.org/show_bug.cgi?id=87544 Reviewed by Darin Adler. Remove fast/block/inline-children-root-linebox-crash.html from the skipped list. New, more complex writing mode flipping test with compositing. * compositing/geometry/flipped-blocks-inline-mapping-expected.txt: Added. * compositing/geometry/flipped-blocks-inline-mapping.html: Added. * platform/mac/Skipped: 2012-05-25 Simon Fraser Terrible performance on http://alliances.commandandconquer.com/ and http://www.lordofultima.com/ https://bugs.webkit.org/show_bug.cgi?id=84410 Reviewed by Dave Hyatt. First part of fixing O(N^2) issues when walking the RenderLayer tree for computeCompositingRequirements(). For each layer that goes into the OverlapMap, we were computing an absolute layer bounds, which requires walking back to the root of the tree. Optimize this when possible by storing a stack of offsets as we walk the tree, and using this stack to do the mapping. The stack of offsets and transforms is managed by RenderGeometryMap. When visiting a RenderLayer, RenderLayerCompositor pushes onto the geometry map stack data about offsets and transforms between the current layer and its stacking-parent. RenderGeometryMap handles the case where the previous renderer pushed is between the current renderer and its container. RenderGeometryMap can also handle callers pushing renderers with multiple containers between them. RenderGeometryMap stores some flags about whether the set of mapping steps in the stack involve transforms, fixed position, or special non-uniform mappings like CSS columns. In some cases, it falls back to mapping via renderers. Once constructed, the RenderGeometryMap stack can be used to map multiple rects or points efficiently. Stacks consisting of simple offsets are collapsed to a single offset. Mappings between renderers and their containers are pushed by pushMappingToContainer() methods, which are similar to mapLocalToContainer() methods. Having this code in RenderObjects was deemed preferable to handling columns, transforms etc. all in RenderLayer code. Tested by assertions in RenderGeometryMap code that its mapping matches mapping via localToAbsolute() calls. RenderLayerCompositor::updateCompositingLayers() creates a RenderGeometryMap, and pushes and pops layer renderers as it visits them. The geometry map is used by RenderLayerCompositor::addToOverlapMap() when computing absolute layer bounds. Futher optimizations in RenderGeometryMap are possible, especially with stacks that have many offsets and a few transforms. Tests: compositing/geometry/composited-in-columns.html compositing/geometry/flipped-writing-mode.html * CMakeLists.txt: Add RenderGeometryMap * GNUmakefile.list.am: Ditt * Target.pri: Ditto * WebCore.gypi: Ditto * WebCore.vcproj/WebCore.vcproj: Ditto * WebCore.xcodeproj/project.pbxproj: Ditto * rendering/RenderBox.cpp: (WebCore::RenderBox::absoluteContentBox): (WebCore::RenderBox::pushMappingToContainer): (WebCore::RenderBox::offsetFromContainer): * rendering/RenderBox.h: * rendering/RenderGeometryMap.cpp: Added. (RenderGeometryMapStep): (WebCore::RenderGeometryMapStep::RenderGeometryMapStep): (WebCore::RenderGeometryMapStep::mapPoint): (WebCore::RenderGeometryMapStep::mapQuad): (WebCore::RenderGeometryMap::RenderGeometryMap): (WebCore::RenderGeometryMap::~RenderGeometryMap): (WebCore::RenderGeometryMap::absolutePoint): (WebCore::RenderGeometryMap::absoluteRect): (WebCore::RenderGeometryMap::mapToAbsolute): (WebCore::RenderGeometryMap::pushMappingsToAncestor): (WebCore::RenderGeometryMap::push): (WebCore::RenderGeometryMap::pushView): (WebCore::RenderGeometryMap::popMappingsToAncestor): (WebCore::RenderGeometryMap::stepInserted): (WebCore::RenderGeometryMap::stepRemoved): * rendering/RenderGeometryMap.h: Added. (RenderGeometryMap): (WebCore::RenderGeometryMap::hasNonUniformStep): (WebCore::RenderGeometryMap::hasTransformStep): (WebCore::RenderGeometryMap::hasFixedPositionStep): * rendering/RenderInline.cpp: (WebCore::RenderInline::offsetFromContainer): (WebCore::RenderInline::pushMappingToContainer): * rendering/RenderInline.h: (RenderInline): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateCompositingLayers): (WebCore::RenderLayerCompositor::addToOverlapMap): (WebCore::RenderLayerCompositor::addToOverlapMapRecursive): (WebCore::RenderLayerCompositor::computeCompositingRequirements): * rendering/RenderLayerCompositor.h: (RenderLayerCompositor): * rendering/RenderObject.cpp: (WebCore::RenderObject::mapLocalToContainer): (WebCore::RenderObject::pushMappingToContainer): (WebCore::RenderObject::offsetFromContainer): (WebCore::RenderObject::container): * rendering/RenderObject.h: * rendering/RenderTableCell.cpp: (WebCore::RenderTableCell::offsetFromContainer): * rendering/RenderTableCell.h: (RenderTableCell): * rendering/RenderView.cpp: (WebCore::RenderView::pushMappingToContainer): * rendering/RenderView.h: * rendering/svg/RenderSVGForeignObject.cpp: (WebCore::RenderSVGForeignObject::pushMappingToContainer): * rendering/svg/RenderSVGForeignObject.h: (RenderSVGForeignObject): * rendering/svg/RenderSVGInline.cpp: (WebCore::RenderSVGInline::pushMappingToContainer): * rendering/svg/RenderSVGInline.h: (RenderSVGInline): * rendering/svg/RenderSVGModelObject.cpp: (WebCore::RenderSVGModelObject::pushMappingToContainer): * rendering/svg/RenderSVGModelObject.h: (RenderSVGModelObject): * rendering/svg/RenderSVGRoot.cpp: (WebCore::RenderSVGRoot::pushMappingToContainer): * rendering/svg/RenderSVGRoot.h: (RenderSVGRoot): * rendering/svg/RenderSVGText.cpp: (WebCore::RenderSVGText::pushMappingToContainer): * rendering/svg/RenderSVGText.h: (RenderSVGText): * rendering/svg/SVGRenderSupport.cpp: (WebCore::SVGRenderSupport::pushMappingToContainer): * rendering/svg/SVGRenderSupport.h: (SVGRenderSupport): 2012-11-14 Beth Dakin Merge r134348 2012-11-12 Beth Dakin https://bugs.webkit.org/show_bug.cgi?id=101787 Zoomed-in scrolling is very slow when deviceScaleFactor > 1 Reviewed by Simon Fraser. This patch adds a new member to the GraphicsContextState that tracks whether or not fonts should be subpixel-quantized. We want to default to sibpixel-quantizing, but we'll turn it off if we're scrolling content that cannot be scrolled on the scrolling thread. State has a new bool shouldSubpixelQuantizeFonts. It defaults to true since normally we do want to quantize. * platform/graphics/GraphicsContext.cpp: (WebCore::GraphicsContext::setShouldSubpixelQuantizeFonts): (WebCore::GraphicsContext::shouldSubpixelQuantizeFonts): * platform/graphics/GraphicsContext.h: (WebCore::GraphicsContextState::GraphicsContextState): (GraphicsContextState): (GraphicsContext): wkSetCGFontRenderingMode now takes a BOOL parameter which indicates whether or not it should try to subpixel-quantize the fonts. * platform/graphics/mac/FontMac.mm: (WebCore::Font::drawGlyphs): * platform/mac/WebCoreSystemInterface.h: * platform/mac/WebCoreSystemInterface.mm: Disable subpixel-quantization for overflow areas, subframes, and content that is scrolling on the main thread. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintLayerContents): 2012-11-13 Lucas Forschler Merge r127508 2012-09-04 Michael Saboff equal() in CSSParser.cpp should check the length of characters https://bugs.webkit.org/show_bug.cgi?id=95706 Reviewed by Abhishek Arya. Pass the length of string literals to CSSParser static functions equal() and equalIgnoringCase() so that checks won't access out of bounds memory. Added test fast/css/crash-comparing-equal.html. * css/CSSParser.cpp: (WebCore::equal): Use template to retrieve the length of string literal. (WebCore::equalIgnoringCase): Ditto. (WebCore::CSSParser::parseDashboardRegions): Use const char[] instead of const char* 2012-11-13 Lucas Forschler Merge r123433 2012-07-24 Kentaro Hara [JSC] REGRESSION(r122912): CodeGeneratorJS.pm should not implicitly assume ScriptExecutionContext for static attributes https://bugs.webkit.org/show_bug.cgi?id=91924 Reviewed by Adam Barth. r122912 implemented static attributes in CodeGeneratorJS.pm. However, the generated code assumes that static attributes always require ScriptExecutionContext, which is wrong. If we need a ScriptExecutionContext, we should specify [CallWith=ScriptExecutionContext]. This patch fixes CodeGeneratorJS.pm so that static attributes do not assume ScriptExecutionContext. This fix aligns with the fix in CodeGeneratorV8.pm in r123308. Test: bindings/scripts/test/TestObj.idl * bindings/scripts/CodeGeneratorJS.pm: (GenerateImplementation): * bindings/scripts/test/JS/JSTestInterface.cpp: (WebCore::jsTestInterfaceConstructorSupplementalStaticReadOnlyAttr): (WebCore::jsTestInterfaceConstructorSupplementalStaticAttr): (WebCore::setJSTestInterfaceConstructorSupplementalStaticAttr): * bindings/scripts/test/JS/JSTestObj.cpp: (WebCore::jsTestObjConstructorStaticReadOnlyIntAttr): (WebCore::jsTestObjConstructorStaticStringAttr): (WebCore::setJSTestObjConstructorStaticStringAttr): 2012-11-13 Lucas Forschler Merge r122912 2012-07-17 Jon Lee Teach CodeGenerator to support for static, readonly, attributes https://bugs.webkit.org/show_bug.cgi?id=88920 Reviewed by Oliver Hunt. Update the parser to be able to accept the static keyword for attribute. We will treat static attributes like custom static functions. They call the implementing class directly, and pass in the ExecState as a script context. * bindings/scripts/CodeGeneratorJS.pm: (GetAttributeGetterName): Factor out the construction of the attribute getter function name. (GetAttributeSetterName): Factor out the construction of the attribute setter function name. (GenerateHeader): Determine that a class has read-write properties only if there is a read-write attribute that is not static. (GenerateAttributesHashTable): Skip static attributes in the object hash table. They will be added to the constructor hash table. (GenerateImplementation): Look for static attributes to add to the constructor hash table. Make a call to the static function in the class. * bindings/scripts/IDLParser.pm: (ParseInterface): Update the processing because of the regex change. * bindings/scripts/IDLStructure.pm: Update the attribute regex. * bindings/scripts/test/JS/JSTestObj.cpp: Update test results. * bindings/scripts/test/JS/JSTestObj.h: Update test results. * bindings/scripts/test/TestObj.idl: Add test cases. 2012-11-13 Lucas Forschler Merge r125280 2012-08-10 Jon Lee Change Notification.permissionLevel() to Notification.permission https://bugs.webkit.org/show_bug.cgi?id=88919 Reviewed by Kentaro Hara. Retrieving the permission level has changed to Notification.permission, per this discussion: http://lists.w3.org/Archives/Public/public-web-notification/2012Jun/0000.html Test: fast/notifications/notifications-permission.html * Modules/notifications/Notification.cpp: Rename to match attribute name. (WebCore::Notification::permission): * Modules/notifications/Notification.h: Rename to match attribute name. (Notification): * Modules/notifications/Notification.idl: Change to static readonly attribute. 2012-11-13 Lucas Forschler Merge r127000 2012-08-29 Alexander Pavlov Web Inspector: Page with @import and :last-child in an edited stylesheet will crash https://bugs.webkit.org/show_bug.cgi?id=95324 Reviewed by Antti Koivisto. Ensure the destroyed StyleRules removal from StyleResolver by creating a separate RuleMutationScope for clearing the StyleSheetContents. Test: inspector/styles/import-pseudoclass-crash.html * inspector/InspectorStyleSheet.cpp: (WebCore::InspectorStyleSheet::reparseStyleSheet): 2012-11-13 Lucas Forschler Rollout r133090 2012-11-12 Lucas Forschler Merge r133469 2012-11-05 Antti Koivisto Protect against resource deletion during iteration in MemoryCache::pruneDeadResourcesToSize https://bugs.webkit.org/show_bug.cgi?id=101211 Reviewed by Andreas Kling. Some crashes have been seen under MemoryCache::pruneDeadResourcesToSize. A possible cause is that destroyDecodedData() call ends up evicting the resource pointed by 'previous' pointer during iteration and deleting the object. This looks in principle possible via stylesheets and SVG images. Speculative fix, no repro, no obvious way to construct a test. * loader/cache/MemoryCache.cpp: (WebCore::MemoryCache::pruneDeadResourcesToSize): Use CachedResourceHandle to protect the 'previous' pointer during iteration. Check if the resource has been kicked out from the cache during destroyDecodedData() and stop iterating if has (as it may die when CachedResourceHandle releases it). The 'current' pointer is not protected as the resource it points to is allowed to die. 2012-11-12 Lucas Forschler Merge r131077 2012-10-11 Dan Bernstein Combined text reverts to full-width font after a style change https://bugs.webkit.org/show_bug.cgi?id=99009 Reviewed by John Sullivan. Test: fast/text/text-combine-width-after-style-change.html * rendering/RenderCombineText.cpp: (WebCore::RenderCombineText::styleDidChange): Changed to reset m_isCombined to false, to ensure that combineText() is called on the next layout. 2012-11-12 Lucas Forschler Merge r131018 2012-10-10 Jer Noble Disallow full screen mode keyboard access by default. https://bugs.webkit.org/show_bug.cgi?id=98971 Reviewed by Sam Weinig. Fall back to requesting non-keyboard access if the client refuses to allow keyboard access. * dom/Document.cpp: (WebCore::Document::requestFullScreenForElement): 2012-11-12 Lucas Forschler Merge r130855 2012-10-09 Philip Rogers Recursively detach SVGElementInstances https://bugs.webkit.org/show_bug.cgi?id=98851 Reviewed by Ryosuke Niwa and Abhishek Arya Before this patch, SVGElementInstance child nodes were not being detached. This patch makes detach() recursively detach SVGElementInstances. * svg/SVGElementInstance.cpp: (WebCore::SVGElementInstance::detach): 2012-11-12 Lucas Forschler Merge r129796 2012-09-27 Philip Rogers Rewrite multithreaded filter job dispatching https://bugs.webkit.org/show_bug.cgi?id=97500 Reviewed by Dean Jackson. This patch solves the problem of splitting up images into subregions for multithreaded filters. This fixes the way we partition the image array into equal-sized chunks. If we have an array of length N and want to split it into K chunks, we calculate: int jobSize = N / K; // integer division, so this is floored int jobSizeExtra = N % K; // modulus produces the remainder We then split the array into jobSizeExtra number of jobs with size jobSize + 1 and (K - jobSizeExtra) number of jobs with size jobSize. This pattern is used in each of the 5 filters in this patch. This patch primarily fixes an error in FEMorphology::platformApply where the image array was partitioned into (1 + (N / K)) pieces with the last job taking the remainder. Unfortunately, this can cause overruns in the 2nd-to-last job. Consider N = 2373 and K = 64 jobs. Job 0 would take indices 0...38, job 1 would take 38...76, etc. Unfortunately the 62nd job takes 2356...2394 which overruns. To prevent similar issues elsewhere this patch updates all of the filters to use the same pattern as FEMorphology. Test: svg/filters/feMorphology-crash.html * platform/graphics/filters/FEConvolveMatrix.cpp: (WebCore::FEConvolveMatrix::platformApplySoftware): * platform/graphics/filters/FEGaussianBlur.cpp: (WebCore::FEGaussianBlur::platformApply): * platform/graphics/filters/FELighting.cpp: (WebCore::FELighting::platformApplyGeneric): * platform/graphics/filters/FEMorphology.cpp: (WebCore::FEMorphology::platformApply): Some special care is taken for Gaussian Blur because there is an extraHeight parameter for sampling outside the image's dimensions. This means we use the same partitioning algorithm but add extraHeight padding on the lower and upper bounds. * platform/graphics/filters/FETurbulence.cpp: (WebCore::FETurbulence::platformApplySoftware): 2012-11-09 Lucas Forschler Merge r132427 2012-10-24 Beth Dakin https://bugs.webkit.org/show_bug.cgi?id=100169 We should make TileCache tiles the size of the tile coverage rect when we can't do fast scrolling -and- Reviewed by Simon Fraser. Some websites that don't do fast scrolling still scroll slower than they do with tiled drawing disabled. https://bugs.webkit.org/show_bug.cgi?id=99768 addressed some of this performance problem, but there is still more ground to make up. This patch addresses the remaining issue by making tiles the size of the window when we can't do fast scrolling. The constructor and create function no longer take a size parameter. That's all fully controlled within TileCache now. m_tileSize is no longer const. * platform/graphics/ca/mac/TileCache.h: Store the current default size as constants so that we can access it in both the constructor and adjustTileSizeForCoverageRect(). * platform/graphics/ca/mac/TileCache.mm: (WebCore::TileCache::TileCache): This new function will set m_tileSize to the size of the tile coverage rect if the tile coverage is limited to the visible area. Otherwise, the tiles are set to be the default size. (WebCore::TileCache::adjustTileSizeForCoverageRect): Call adjustTileSizeForCoverageRect(). (WebCore::TileCache::revalidateTiles): No need to send in a size anymore. * platform/graphics/ca/mac/WebTileCacheLayer.h: (WebCore): 2012-11-09 Lucas Forschler Merge r131939 2012-10-19 Beth Dakin https://bugs.webkit.org/show_bug.cgi?id=99768 We should limit the tile cache coverage when a page can't take advantage of fast tile scrolling anyway Reviewed by Simon Fraser. When sites can't use fast-scrolling, there is no need to inflate the tile cache. In fact, we get a performance boost by keeping it small on painting-intensive sites. Instead of just looking a whether or not the FrameView canHaveScrollbar(), consult shouldUpdateScrollLayerPositionOnMainThread(). * page/FrameView.cpp: (WebCore::FrameView::performPostLayoutTasks): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::RenderLayerBacking): Expose shouldUpdateScrollLayerPositionOnMainThread(). * page/scrolling/ScrollingCoordinator.cpp: (WebCore::ScrollingCoordinator::hasNonLayerFixedObjects): (WebCore::ScrollingCoordinator::shouldUpdateScrollLayerPositionOnMainThread): (WebCore): (WebCore::ScrollingCoordinator::updateShouldUpdateScrollLayerPositionOnMainThread): * page/scrolling/ScrollingCoordinator.h: (ScrollingCoordinator): Bug fix. Should be bitwise and. * platform/graphics/ca/mac/TileCache.mm: (WebCore::TileCache::tileCoverageRect): 2012-11-09 Lucas Forschler Merge r130236 2012-10-02 Simon Fraser Make TiledBacking slightly less aware of scrolling https://bugs.webkit.org/show_bug.cgi?id=98216 Reviewed by Anders Carlsson. TiledBacking shouldn't really care about there being scrollbars; recast this in terms of "tile coverage", described by a bitfield that has flags for coverage optimized for horizontal and vertical scrolling. This allows for additional tile coverage behaviors later. * page/FrameView.cpp: (WebCore::FrameView::performPostLayoutTasks): * platform/graphics/TiledBacking.h: * platform/graphics/ca/mac/TileCache.h: * platform/graphics/ca/mac/TileCache.mm: (WebCore::TileCache::TileCache): Initialize m_isInWindow to false to be more conservative. It gets explicitly set by the only caller now, so this is not a behavior change. (WebCore::TileCache::setIsInWindow): (WebCore::TileCache::setTileCoverage): (WebCore::TileCache::tileCoverageRect): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::RenderLayerBacking): 2012-11-09 Lucas Forschler Merge r126251. 2012-08-21 Julien Chaffraix Crash in RenderTableSection::setCellLogicalWidths https://bugs.webkit.org/show_bug.cgi?id=94291 Reviewed by Abhishek Arya. This issue was that splitAnonymousBoxesAroundChild would move a table section into a newly created table *without* marking it as needing cell recalc. The table would thus never build its structure to match its sections. The fix is to hop on the new willBeRemovedFromTree signal so that the section invalidates itself properly. Test: fast/table/crash-split-table-section-no-cell-recalc.html * rendering/RenderTableSection.cpp: (WebCore::RenderTableSection::willBeRemovedFromTree): * rendering/RenderTableSection.h: Replaced willBeDestroyed by willBeRemovedFromTree in RenderTableSection. This ensures that it is called when moving sections in the tree to mark them as needing cell recalc. 2012-11-09 Lucas Forschler Merge r126048. Prerequisite for 2012-08-20 Julien Chaffraix Introduce a will-be-removed-from-tree notification in RenderObject https://bugs.webkit.org/show_bug.cgi?id=94271 Reviewed by Abhishek Arya. Following bug 93874, we have an insertion notification. This change adds the matching removal notification (willBeRemovedFromTree). Refactoring covered by existing tests. * rendering/RenderObjectChildList.cpp: (WebCore::RenderObjectChildList::removeChildNode): Removed the code from here and moved it below. * rendering/RenderObject.cpp: (WebCore::RenderObject::willBeRemovedFromTree): * rendering/RenderObject.h: This is the base function that should be called by every instance. * rendering/RenderListItem.cpp: (WebCore::RenderListItem::willBeRemovedFromTree): * rendering/RenderListItem.h: * rendering/RenderQuote.cpp: (WebCore::RenderQuote::willBeRemovedFromTree): * rendering/RenderQuote.h: * rendering/RenderRegion.cpp: (WebCore::RenderRegion::willBeRemovedFromTree): * rendering/RenderRegion.h: Overriden functions. 2012-11-09 Lucas Forschler Merge r125737. Prerequisite for 2012-08-15 Julien Chaffraix Add a was-inserted-into-tree notification to RenderObject https://bugs.webkit.org/show_bug.cgi?id=93874 Reviewed by Eric Seidel. This change adds insertedIntoTree to RenderObject so that renderers can now do their post-insertion task inside this function. Our current architecture has 2 ways of doing post-insertion tasks: - overriding RenderObject::addChild - RenderObjectChildList::insertChildNode / appendChildNode Because the former is not guaranteed to be called for each insertion (on top of being called on the parent and not the inserted child), the 2 latter functions are the one that have been mostly used recently. This led to code duplication between the functions but also doesn't scale as other renderers need to hop on this notification and currently don't (for example, table parts). The other renderer's migration will be done in follow-up patches. Refactoring covered by existing tests. * rendering/RenderObjectChildList.cpp: (WebCore::RenderObjectChildList::removeChildNode): * rendering/RenderObject.cpp: (WebCore::RenderObject::enclosingRenderNamedFlowThread): Moved the code from renderNamedFlowThreadContainer to RenderObject::enclosingRenderNamedFlowThread. This is needed as now 2 classes need to access the function. * rendering/RenderObjectChildList.cpp: (WebCore::RenderObjectChildList::appendChildNode): (WebCore::RenderObjectChildList::insertChildNode): Moved the code duplicated from those 2 functions into the instances of insertedIntoTree below. * rendering/RenderObject.cpp: (WebCore::RenderObject::insertedIntoTree): Base function that needs to be called from all the other specialized functions below. * rendering/RenderListItem.cpp: (WebCore::RenderListItem::insertedIntoTree): * rendering/RenderListItem.h: * rendering/RenderObject.h: * rendering/RenderObjectChildList.h: * rendering/RenderRegion.cpp: (WebCore::RenderRegion::insertedIntoTree): * rendering/RenderRegion.h: Added the overriden insertedIntoTree function. * rendering/RenderQuote.h: Moved the comment from RenderObjectChildList about RenderQuote here. 2012-11-09 Lucas Forschler Merge r125635 2012-08-14 Ojan Vafai Fix access to m_markupBox in WebCore::EllipsisBox::paint https://bugs.webkit.org/show_bug.cgi?id=91138 Reviewed by Abhishek Arya. EllipsisBox would hold on to m_markupBox, which would then get destroyed during the followup layoutIfNeeded in layoutVerticalBox. Instead, have EllipsisBox dynamically grab to pointer to the markup box during paint since there's no straightforward way to notify the EllipsisBox that the markupBox has been destroyed and/or point it at the new markupBox. Test: fast/overflow/line-clamp-and-columns.html * rendering/EllipsisBox.cpp: (WebCore::EllipsisBox::paint): (WebCore): (WebCore::EllipsisBox::paintMarkupBox): * rendering/EllipsisBox.h: (WebCore::EllipsisBox::EllipsisBox): Just store a boolean that we have a markup box that needs painting. * rendering/RenderDeprecatedFlexibleBox.cpp: (WebCore::RenderDeprecatedFlexibleBox::applyLineClamp): Clearing the override size right after setting it was incorrect because there are cases where we'll do a followup layout in layoutVerticalBox, at which point we'll still need the override size. (WebCore::RenderDeprecatedFlexibleBox::clearLineClamp): Clear the override size here to handle cases where line clamp is removed since we don't call applyLineClamp in those cases. 2012-11-08 Lucas Forschler Merge r125597 2012-08-13 Adrienne Walker REGRESSION (r109851): Video controls do not render https://bugs.webkit.org/show_bug.cgi?id=93859 Reviewed by Simon Fraser. Because video layers can't act as an ancestor composited layer whose backing can be shared by child layers, any child layer of a video layer needs to be put into its own composited layer. Because this is technically overlap, the "overlap" indirect compositing reason is reused for this case. Test: compositing/video/video-controls-layer-creation.html * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::computeCompositingRequirements): 2012-11-07 Lucas Forschler Merge r129652 2012-09-26 Brady Eidson (Threaded scrolling) WebKit not scrolling to the correct location upon going back on macsurfer.com and https://bugs.webkit.org/show_bug.cgi?id=97617 Reviewed by Anders Carlsson. In the asynchronous land of threaded scrolling we lose the information about whether or not a scroll is programmatic. This caused all scrolls to be treated as user scrolls and to generated scroll events. We can fix this by passing the programmatic bit to the scrolling thread and re-applying it back in the main thread. Unable to test threaded scrolling at this time. Include the "Is programmatic scroll" bit in the scroll state: * page/scrolling/ScrollingTreeState.cpp: (WebCore::ScrollingTreeState::ScrollingTreeState): (WebCore::ScrollingTreeState::setRequestedScrollPosition): Also set whether or not this represents a programmatic scroll. * page/scrolling/ScrollingTreeState.h: (ScrollingTreeState): (WebCore::ScrollingTreeState::requestedScrollPositionRepresentsProgrammaticScroll): Pass that bit back to the ScrollingCoordinator: * page/scrolling/ScrollingTree.cpp: (WebCore::ScrollingTree::ScrollingTree): (WebCore::ScrollingTree::commitNewTreeState): (WebCore::ScrollingTree::updateMainFrameScrollPosition): * page/scrolling/ScrollingTree.h: * page/scrolling/ScrollingCoordinator.cpp: (WebCore::ScrollingCoordinator::requestScrollPositionUpdate): Pass the "is programmatic scroll" bit to the scrolling thread. (WebCore::ScrollingCoordinator::updateMainFrameScrollPosition): Reset the "is programmatic scroll" bit on the FrameView. * page/scrolling/ScrollingCoordinator.h: (ScrollingCoordinator): * page/FrameView.h: (FrameView): (WebCore::FrameView::inProgrammaticScroll): Expose setter/getters for the programmatic scroll flag. (WebCore::FrameView::setInProgrammaticScroll): 2012-11-06 Lucas Forschler Merge r129469 2012-09-25 MORITA Hajime adoptNode() shouldn't reset ownerDocument if the source node failed to remove itself https://bugs.webkit.org/show_bug.cgi?id=97527 Reviewed by Ryosuke Niwa. Document::adoptNode() overlooked an error which can happen in Node::removeChild(). Which results an assertion failure. This change adds an error check for that code path. Test: fast/dom/adopt-node-prevented.html * dom/Document.cpp: (WebCore::Document::adoptNode): 2012-11-06 Lucas Forschler Merge r129270 2012-09-21 Jeremy Apthorp Crash in WebCore::Document::fullScreenChangeDelayTimerFired https://bugs.webkit.org/show_bug.cgi?id=97367 Reviewed by Abhishek Arya. The document could be destroyed during the processing of the fullscreenchange event, if the document was destroyed as a result of one of the dispatchEvent calls. This bug isn't reliably reproducible, so no new tests. * dom/Document.cpp: (WebCore::Document::fullScreenChangeDelayTimerFired): 2012-11-06 Lucas Forschler Merge r128964 2012-09-18 Eric Carlson Check settings before registering AVFoundation media engine. https://bugs.webkit.org/show_bug.cgi?id=97048 Reviewed by Dan Bernstein. Fix the bug introduced in r122676. * platform/graphics/MediaPlayer.cpp: (WebCore::installedMediaEngines): Uncomment the call to check AVFoundation settings. 2012-11-06 Lucas Forschler Merge r128654 2012-09-14 Tom Sepez ImageLoader can't be cleared when video element poster attribute removed. https://bugs.webkit.org/show_bug.cgi?id=96301 Reviewed by Abhishek Arya. Same problem as in https://bugs.webkit.org/show_bug.cgi?id=90801. We can't clear the image loader when the src attribute is cleared, because we might be inside a handler called on top of an image loader event dispatch. Instead we will rely on the OwnPtr relationship between the Element and the Image Loader to limit the lifetime of the loader to that of the element. Test: fast/dom/beforeload/clear-video-poster-in-beforeload-listener.html * html/HTMLVideoElement.cpp: (WebCore::HTMLVideoElement::parseAttribute): Remove permature clearing of m_imageLoader. * html/HTMLEmbedElement.cpp: (WebCore::HTMLEmbedElement::parseAttribute): Remove permature clearing of m_imageLoader. * html/HTMLObjectElement.cpp: (WebCore::HTMLObjectElement::parseAttribute): Remove permature clearing of m_imageLoader. 2012-11-06 Lucas Forschler Merge r127082 2012-08-29 Michael Saboff use after free in WebCore::FileReader::doAbort https://bugs.webkit.org/show_bug.cgi?id=91004 Reviewed by Jian Li. Added check in FileReader::abort to not process the abort if we aren't in the LOADING state. This is per the FileAPI spec section 8.5.6 step #1. Tests: fast/files/file-reader-immediate-abort.html fast/files/file-reader-done-reading-abort.html * fileapi/FileReader.cpp: (WebCore::FileReader::abort): 2012-11-06 Lucas Forschler Merge r126657 2012-08-24 Florin Malita ASSERTION FAILED: !attached() in WebCore::Node::attach() https://bugs.webkit.org/show_bug.cgi?id=94650 Reviewed by Abhishek Arya. Prevent SVGTests::handleAttributeChange() from attaching elements with detached parents. Test: svg/custom/system-language-crash.html * svg/SVGTests.cpp: (WebCore::SVGTests::handleAttributeChange): 2012-11-06 Lucas Forschler Merge r126205 2012-08-21 Florin Malita ASSERT triggered in SVGTRefTargetEventListener::handleEvent() https://bugs.webkit.org/show_bug.cgi?id=94487 Reviewed by Nikolas Zimmermann. The current way of tracking tref target elements by id can leave stale event listeners under certain circumstances. This patch switches to storing a target RefPtr instead to avoid an id lookup which may not return the original/attached element. Test: svg/custom/tref-stale-listener-crash.html * svg/SVGTRefElement.cpp: (SVGTRefTargetEventListener): (WebCore::SVGTRefTargetEventListener::isAttached): use m_target instead of an explicit bool. (WebCore::SVGTRefTargetEventListener::SVGTRefTargetEventListener): (WebCore::SVGTRefTargetEventListener::attach): save a target RefPtr instead of an id. (WebCore::SVGTRefTargetEventListener::detach): detach the target element directly without going through a lookup. (WebCore::SVGTRefTargetEventListener::handleEvent): (WebCore::SVGTRefElement::updateReferencedText): use an explicit target pointer instead of the id-based lookup. (WebCore::SVGTRefElement::buildPendingResource): * svg/SVGTRefElement.h: (SVGTRefElement): 2012-11-06 Lucas Forschler Merge r126131 2012-08-20 MORITA Hajime load event shouldn't fired during node insertion traversals. https://bugs.webkit.org/show_bug.cgi?id=94447 Reviewed by Ryosuke Niwa. HTMLFrameElementBase::didNotifyDescendantInsertions() with empty @src can trigger a load event during ChildNodeInsertionNotifier traversal, whose handler can make DOM tree state inconsistent. This change introduces a post traversal hook, didNotifySubtreeInsertions(), for the insertion traversal and replaces the problematic didNotifyDescendantInsertions() with it. Since didNotifySubtreeInsertions() is invoked after the traversal, it is safe for event handlers to mutate the tree. Test: fast/frames/iframe-onload-and-domnodeinserted.html * dom/ContainerNodeAlgorithms.h: (ChildNodeInsertionNotifier): Added a post subtree notification. (WebCore::ChildNodeInsertionNotifier::notifyNodeInsertedIntoDocument): (WebCore::ChildNodeInsertionNotifier::notify): * dom/Node.h: (WebCore::Node::didNotifySubtreeInsertions): Newly added. * html/HTMLFrameElementBase.cpp: (WebCore::HTMLFrameElementBase::insertedInto): Now returns InsertionShouldCallDidNotifySubtreeInsertions (WebCore::HTMLFrameElementBase::didNotifySubtreeInsertions): Replaced didNotifyDescendantInsertions() * html/HTMLFrameElementBase.h: (HTMLFrameElementBase): 2012-11-06 Lucas Forschler Merge r125988 2012-08-19 MORITA Hajime DOM mutation against including shouldn't trigger pending HTML parser. https://bugs.webkit.org/show_bug.cgi?id=93641 Reviewed by Ryosuke Niwa. HTMLLinkElement::removedFrom() invoked Document::removePendingSheet(), which can trigger HTMLParser that can mutate DOM tree. DOM mutation reentrancy on like this is problematic and should be prohibited. This change add an variation of Document::removePendingSheet() which postpones the notification which triggers DOM mutation, and flush such pending notifications at the end of ongoing mutation. Test: http/tests/loading/remove-child-triggers-parser.html * dom/ContainerNodeAlgorithms.h: (WebCore::ChildNodeRemovalNotifier::notify): Flushed pending notifications at the end. * dom/Document.cpp: (WebCore::Document::Document): (WebCore::Document::removePendingSheet): Added RemovePendingSheetNotificationType parameter. (WebCore): (WebCore::Document::didRemoveAllPendingStylesheet): Extracted from removePendingSheet() * dom/Document.h: (Document): (WebCore::Document::setNeedsNotifyRemoveAllPendingStylesheet): A flag setter. (WebCore::Document::notifyRemovePendingSheetIfNeeded): (WebCore): * html/HTMLLinkElement.cpp: (WebCore::HTMLLinkElement::removedFrom): Switched to use "notification later" version of removePendingSheet() (WebCore::HTMLLinkElement::removePendingSheet): Added RemovePendingSheetNotificationType parameter. * html/HTMLLinkElement.h: 2012-11-06 Lucas Forschler Merge r125631 2012-08-14 Chris Evans Handle the XPath / (root) operator correctly for nodes that aren't attached to the document. https://bugs.webkit.org/show_bug.cgi?id=36427 Reviewed by Abhishek Arya. We now behave the same as Firefox 14. The consensus seems to be that the XPath spec is ambiguous for the case of detached nodes, and that using the fragment root is more intuitive than the document root for the case of detached nodes. For example, http://www.w3.org/TR/xpath/ section 2 "Location Paths" is only clear for attached nodes: "A / by itself selects the root node of the document containing the context node. If it is followed by a relative location path, then the location path selects the set of nodes that would be selected by the relative location path relative to the root node of the document containing the context node." Test: fast/xpath/xpath-detached-nodes.html * xml/XPathPath.cpp: (WebCore::XPath::LocationPath::evaluate): Jump to the root of the detached subtree instead of the parent document if the node isn't attached to the document. 2012-11-06 Lucas Forschler Merge r125503 2012-08-13 Douglas Stockwell Crash in WebCore::RenderBlock::LineBreaker::nextLineBreak https://bugs.webkit.org/show_bug.cgi?id=93806 Reviewed by Abhishek Arya. When looking for line breaks on the first line, existing code was checking for text-combine only in the first-line style. Since text-combine isn't inherited this resulted in a line break being chosen before combineText was called. When this happened and then combineText was called subsequently, the position of the line break iterator would be invalid. This patch changes the check to use the regular style as in skipLeadingWhitespace and textWidth. Test: fast/text/text-combine-first-line-crash.html * rendering/RenderBlockLineLayout.cpp: (WebCore::RenderBlock::LineBreaker::nextLineBreak): Don't use the first-line style when checking text-combine. 2012-11-05 Lucas Forschler Merge r125353 2012-08-11 Abhishek Arya Unreviewed. Removing newly added assert in r125351 since it is exposing legitimate layout bugs in few tests. We will re-add the assert after fixing those bugs. Failures are tracked in webkit bug 93766. * rendering/RenderBlock.cpp: (WebCore::RenderBlock::removeFromTrackedRendererMaps): 2012-11-05 Lucas Forschler Merge r125351 2012-08-11 Levi Weintraub Track block's positioned objects like percent-height descendants https://bugs.webkit.org/show_bug.cgi?id=89848 Reviewed by Abhishek Arya. The previous method for tracking a RenderBlock's out-of-flow positioned descendants was error prone, subject to becoming inconsistent, and in the case of removePositionedObjects, inefficient. This patch extracts the algorithm used for percent height descendants and re-uses it for positioned objects. This same method could further be re-used for floats. This change removes the m_positionedObjects pointer, which brings RenderBlock's size down (yay!). Test: fast/block/positioning/relayout-nested-positioned-elements-crash-2.html * rendering/RenderBlock.cpp: (SameSizeAsRenderBlock): (WebCore): (WebCore::removeBlockFromDescendantAndContainerMaps): (WebCore::RenderBlock::~RenderBlock): (WebCore::RenderBlock::addOverflowFromPositionedObjects): (WebCore::RenderBlock::layoutBlockChildren): (WebCore::RenderBlock::layoutPositionedObjects): (WebCore::RenderBlock::markPositionedObjectsForLayout): (WebCore::clipOutPositionedObjects): (WebCore::RenderBlock::selectionGaps): (WebCore::RenderBlock::insertIntoTrackedRendererMaps): (WebCore::RenderBlock::removeFromTrackedRendererMaps): (WebCore::RenderBlock::positionedObjects): (WebCore::RenderBlock::insertPositionedObject): (WebCore::RenderBlock::removePositionedObject): (WebCore::RenderBlock::removePositionedObjects): (WebCore::RenderBlock::addPercentHeightDescendant): (WebCore::RenderBlock::removePercentHeightDescendant): (WebCore::RenderBlock::percentHeightDescendants): (WebCore::RenderBlock::checkPositionedObjectsNeedLayout): * rendering/RenderBlock.h: (WebCore): (RenderBlock): (WebCore::RenderBlock::hasPositionedObjects): * rendering/RenderBox.cpp: (WebCore::RenderBox::removeFloatingOrPositionedChildFromBlockLists): * rendering/RenderBoxModelObject.cpp: (WebCore::RenderBoxModelObject::moveChildTo): Changing the fixme to reflect the assumption that the caller has taken care of updating the positioned renderer maps is a decision not a bug. The ASSERT should help assure this. * rendering/RenderTableSection.cpp: (WebCore::RenderTableSection::layoutRows): * rendering/RenderView.cpp: (WebCore::RenderView::setFixedPositionedObjectsNeedLayout): 2012-11-05 Lucas Forschler Merge r125315 2012-08-10 Abhishek Arya Crash on accessing a removed layout root in FrameView::scheduleRelayout. https://bugs.webkit.org/show_bug.cgi?id=91368 Reviewed by Levi Weintraub. We were calling setNeedsLayoutAndPrefWidthsRecalc() in RenderBlock::collapseAnonymousBoxChild even when documentBeingDestroyed() was true. This ends up accessing stale layout root and bypasses mitigation added in r109406. There is no need to waste time merging up anonymous blocks in RenderBlock::removeChild when documentBeingDestroyed() is true. No new tests. The test is time sensitive, requires a bunch of reloads, and only reproduces on chromium linux. * rendering/RenderBlock.cpp: (WebCore::RenderBlock::collapseAnonymousBoxChild): (WebCore::RenderBlock::removeChild): 2012-11-05 Lucas Forschler Merge r125237 2012-08-09 MORITA Hajime https://bugs.webkit.org/show_bug.cgi?id=93587 Node::replaceChild() can create bad DOM topology with MutationEvent, Part 2 Reviewed by Kent Tamura. This is a followup of r124156. replaceChild() has yet another hidden MutationEvent trigger. This change added a guard for it. Test: fast/events/mutation-during-replace-child-2.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::replaceChild): 2012-11-05 Lucas Forschler Merge r125234 2012-08-09 Julien Chaffraix Crash in WebCore::RenderTable::cellBefore https://bugs.webkit.org/show_bug.cgi?id=91160 Reviewed by Abhishek Arya. The issue was that we wouldn't properly set the row index on row in a newly split table. When inserting the cell into the new row, we would try to repaint the cell which would access the row index and crash. This came from splitAnonymousBoxesAroundChild calling RenderObjectChildList::insertChildNode directly which doesn't invoke the row setting logic (RenderTableSection::addChild for example but we cannot call addChild due to concern over splitting flows in the general case). Test: fast/table/split-anonymous-boxes-around-table-repaint-crash.html * rendering/RenderBox.cpp: (WebCore::RenderBox::splitAnonymousBoxesAroundChild): Dirty our parent box, which forces a cell recomputation which will set the row index. This needs to be done *before* we insert the child to avoid crashing when repainting the new child. 2012-11-05 Lucas Forschler Merge r125162 2012-08-09 MORITA Hajime DOMCharacterDataModified should not be fired inside shadows https://bugs.webkit.org/show_bug.cgi?id=93427 Reviewed by Ryosuke Niwa. CharacterData::dispatchModifiedEvent() fires DOMCharacterDataModified event even if the node is in shadow. But it shouldn't. Check dispatchChildInsertionEvents() and dispatchChildRemovalEvents() to see how other MutationEvents are suppressed behind shadows. This change follows the same path to suppress DOMCharacterDataModified. Tests: fast/dom/shadow/suppress-mutation-events-in-shadow-characterdata.html fast/forms/textarea-and-mutation-events-appending-text.html * dom/CharacterData.cpp: (WebCore::CharacterData::dispatchModifiedEvent): 2012-11-05 Lucas Forschler Merge r125147 2012-08-08 MORITA Hajime [SVG] load events shouldn't be fired during Node::insrtedInto() https://bugs.webkit.org/show_bug.cgi?id=92969 Reviewed by Ryosuke Niwa. Event dispatches during insertedInto() allow event handlers to break DOM tree cosistency. This chagne makes them async for load events which are dispatched during insertedInto() call. This prevents event handlers from breaking tree consistency while the notification traversal. Test: svg/custom/loadevents-async.html * svg/SVGElement.cpp: (WebCore::SVGElement::sendSVGLoadEventIfPossibleAsynchronously): Added. (WebCore): (WebCore::SVGElement::svgLoadEventTimerFired): Added. (WebCore::SVGElement::svgLoadEventTimer): - Added a stub. Implemented in SVGScriptElement, SVGStopElement, SVGUseElement where the load event happens. * svg/SVGElement.h: (SVGElement): * svg/SVGExternalResourcesRequired.cpp: (WebCore::SVGExternalResourcesRequired::insertedIntoDocument): - Replaces event dispatch call with async version. * svg/SVGScriptElement.h: * svg/SVGStyleElement.h: * svg/SVGUseElement.h: 2012-11-05 Lucas Forschler Merge r125091 2012-08-08 Beth Dakin https://bugs.webkit.org/show_bug.cgi?id=92275 Need a way to get a snapshot image that does not show the selection -and corresponding- Reviewed by Anders Carlsson. New function FrameView::paintContentsForSnapshot() has the option to exclude selection from the snapshot. Export new function * WebCore.exp.in: Clear the selection from the RenderView when selection is to be excluded. Restore all of this information via FrameSelection::updateAppearance() after calling paintContents(). * page/FrameView.cpp: (WebCore::FrameView::paintContentsForSnapshot): (WebCore): * page/FrameView.h: 2012-11-05 Lucas Forschler Merge r125052 2012-08-08 Tom Sepez Video element image loader must persist after element detach. https://bugs.webkit.org/show_bug.cgi?id=90801 Reviewed by Eric Carlson. We rely on the OwnPtr in the element to cleanup the loader. Test: fast/dom/beforeload/remove-video-poster-in-beforeload-listener.html * html/HTMLVideoElement.cpp: (WebCore): * html/HTMLVideoElement.h: (HTMLVideoElement): 2012-11-05 Lucas Forschler Merge r124924 2012-08-07 Anders Carlsson Knob slot animation is flipped https://bugs.webkit.org/show_bug.cgi?id=93396 Reviewed by Beth Dakin. When painting the scrollbar knob slot, use rectForPart: since it correctly takes the expansion transition state into account. * platform/mac/ScrollbarThemeMac.mm: (WebCore::scrollbarPainterPaint): 2012-11-05 Lucas Forschler Merge r124919 2012-08-07 Adrienne Walker 50% fixed position coverage slow scroll heuristic is incorrect when invalidations aren't clipped https://bugs.webkit.org/show_bug.cgi?id=92011 Reviewed by Simon Fraser. The heuristic in scrollContentsFastPath to slow scroll by invalidating the entire frame if fixed position elements cover 50% of the frame takes away the ability of ports to make their own decisions about how to best handle invalidations. Therefore, remove this heuristic. * page/FrameView.cpp: (WebCore::FrameView::scrollContentsFastPath): 2012-11-05 Lucas Forschler Merge r124914 2012-08-07 Abhishek Arya Crash in ContainerNode::cloneChildNodes. https://bugs.webkit.org/show_bug.cgi?id=93378 Reviewed by Levi Weintraub. Re-enabling the editing delete button controller in cloneChildNode was causing style changes, thereby causing load events to fire. The load event can blow our nodes from underneath. This causes crashes when we are nested inside cloneChildNodes. The patch just skips the delete button controller's container element from being cloned and removes the hacky enable/disable logic. Test: fast/dom/clone-node-load-event-crash.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::cloneChildNodes): 2012-11-05 Lucas Forschler Merge r124888 2012-08-07 Abhishek Arya Crash in InlineFlowBox::deleteLine. https://bugs.webkit.org/show_bug.cgi?id=88795 Reviewed by Tony Chang. When we move the fullscreen object from its parent to RenderFullScreen, we forgot to clear the line box tree underneath the object's containing block and mark it for layout. Before the patch, the containing block never got laid out and maintained references to removed line boxes (since the object moved under RenderFullScreen did get laid out and its lineboxes replaced with new ones). Test: fullscreen/full-screen-line-boxes-crash.html * rendering/RenderFullScreen.cpp: (RenderFullScreen::wrapRenderer): 2012-11-05 Lucas Forschler Merge r124843 2012-08-06 Shinya Kawanaka Crash in GenericEventQueue::timerFired since the owner of GenericEventQueue is deleted during dispatching events. https://bugs.webkit.org/show_bug.cgi?id=92946 Reviewed by Eric Carlson. In GenericEventQueue::timerFired(), the owner of GenericEventQueue might be deleted. We have to protect the owner of GenericEventQueue during dispatching events. Test: media/event-queue-crash.html * dom/GenericEventQueue.cpp: (WebCore::GenericEventQueue::timerFired): Added a protection. 2012-11-02 Lucas Forschler Merge r124776 2012-08-06 Abhishek Arya Crash in FrameLoader::stopAllLoaders. https://bugs.webkit.org/show_bug.cgi?id=90805 Reviewed by Nate Chapin. Calling m_provisionalDocumentLoader->stopLoading() can blow away the frame from underneath. Protect it with a RefPtr. No new tests. We don't have a reliable testcase to reproduce this. However, the crash and free stack from ClusterFuzz point clearly at the bug. * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopAllLoaders): 2012-11-02 Lucas Forschler Merge r124733 2012-08-05 Philip Rogers Fix assertion during detach of SVG wrappers without baseVal https://bugs.webkit.org/show_bug.cgi?id=93063 Reviewed by Nikolas Zimmermann. r131583 introduced a change where SVGAnimatedListPropertyTearOff required a baseVal to be set before detaching wrappers. This caused an assertion to be hit if no baseVal was set. This patch changes this behavior so that wrappers are detached even if no baseVal is set. Test: svg/animations/dynamic-modify-transform-without-baseval.html * svg/properties/SVGAnimatedListPropertyTearOff.h: (WebCore::SVGAnimatedListPropertyTearOff::detachListWrappers): * svg/properties/SVGListProperty.h: (WebCore::SVGListProperty::detachListWrappersAndResize): Extracted this static method for detaching wrappers without needing an SVGListProperty. (SVGListProperty): (WebCore::SVGListProperty::detachListWrappers): 2012-11-02 Lucas Forschler Merge r124681 2012-08-03 Florin Malita [SVG] Tref target event listener cleanup https://bugs.webkit.org/show_bug.cgi?id=93004 Reviewed by Abhishek Arya. Currently SVGTRefElement allocates event listeners dynamically as it attaches to its targets. Synchronizing the lifetime of the target listener vs. the tref element is error prone, as various events can stack and trigger nested handlers. In order to reduce complexity and address a couple of outstanding issues, this patch changes the way event listeners are allocated: only one target listener is created for the lifetime of the SVGTRefElement, and gets reused if the target element changes. Test: svg/custom/tref-nested-events-crash.svg * dom/EventListener.h: Added new target event listener type. * svg/SVGTRefElement.cpp: (WebCore): (WebCore::SVGTRefTargetEventListener::create): (WebCore::SVGTRefTargetEventListener::cast): (SVGTRefTargetEventListener): (WebCore::SVGTRefTargetEventListener::isAttached): (WebCore::SVGTRefTargetEventListener::SVGTRefTargetEventListener): (WebCore::SVGTRefTargetEventListener::attach): (WebCore::SVGTRefTargetEventListener::detach): (WebCore::SVGTRefTargetEventListener::operator==): (WebCore::SVGTRefTargetEventListener::handleEvent): No need to check m_trefElement anymore - the listener is allocated for the whole element lifetime, detached when the element is removed and deallocated when the element is destroyed. (WebCore::SVGTRefElement::SVGTRefElement): Allocate one target listener per element, at construction time. (WebCore::SVGTRefElement::~SVGTRefElement): Detach the listener if necessary. (WebCore::SVGTRefElement::detachTarget): Check whether the element is still in document after updating the text (may have been removed by event handlers). (WebCore::SVGTRefElement::buildPendingResource): Attach the event listener before updating the text content to avoid racing with event handlers (which can remove the element). (WebCore::SVGTRefElement::removedFrom): * svg/SVGTRefElement.h: (WebCore): (SVGTRefElement): 2012-11-02 Lucas Forschler Merge r124654 2012-08-03 Dan Bernstein REGRESSION (Safari 5.1 - 6): Cannot correctly display Traditional Mongolian Script https://bugs.webkit.org/show_bug.cgi?id=92864 Reviewed by Sam Weinig. Test: platform/mac/fast/text/combining-character-sequence-vertical.html * platform/graphics/SimpleFontData.cpp: (WebCore::SimpleFontData::glyphForCharacter): Added this helper function. * platform/graphics/SimpleFontData.h: (SimpleFontData): Declared glyphDataForCharacter. * platform/graphics/mac/FontComplexTextMac.cpp: (WebCore::Font::fontDataForCombiningCharacterSequence): Added logic to use the appropriate variant of each font in the fallback list, which mimcs the equivalent logic in glyphDataAndPageForCharacter(). 2012-11-02 Lucas Forschler Merge r124645 2012-08-03 Anna Cavender Negative timestamps for TextTrackCues should not be allowed. https://bugs.webkit.org/show_bug.cgi?id=92939 Reviewed by Eric Carlson. Make sure cues added in JavaScript are not allowed negative timestamps. Attempting to add a cue with a negative timestamp is not successful and setting a timestamp to a negative value has no effect. Test: media/track/track-cue-negative-timestamp.html * html/track/TextTrack.cpp: (WebCore::TextTrack::addCue): If the cue's startTime or endTime is negative, do not add the cue. * html/track/TextTrackCue.cpp: (WebCore::TextTrackCue::setStartTime): Ignore negative values. (WebCore::TextTrackCue::setEndTime): Ignore negative values. * html/track/TextTrackCueList.cpp: (WebCore::TextTrackCueList::add): Add ASSERTs to check startTime and endTime are positive. 2012-11-02 Lucas Forschler Merge r124631 2012-08-03 Stephen Chenney Crash when a clip path referencing a clip path changes documents https://bugs.webkit.org/show_bug.cgi?id=93023 Reviewed by Dirk Schulze. The SVGClipPathElement is set to not need pending resource handling, when in fact it can have pending resources. The result is a crash when the element is moved to a new document (which deletes all resources and leaves them pending) and then immediately deleted (which asserts that there are no pending resources). There is code to remove pending resources upon deletion and removal from the DOM, but it was not executing for clips because of the aforementioned code claiming that clips don't require such handling. The assertion that there be no pending resources is necessary to prevent caches of pending resources from trying to access the deleted element. This change removes the check for needsPendingResourceHandling in SVGStyledElement upon deletion and removal from the DOM. Pending resources will always be checked in such cases to ensure we do not introduce security issues. Test: svg/custom/clip-path-document-change-assert.html * svg/SVGStyledElement.cpp: (WebCore::SVGStyledElement::~SVGStyledElement): Removed needsPendingResourceHandling in the conditional to clean up resources. (WebCore::SVGStyledElement::removedFrom): Removed needsPendingResourceHandling in the conditional to clean up resources. 2012-11-02 Lucas Forschler Merge r124626 2012-07-20 Jon Lee Crash in Notification when setting a non-object as an event listener (91881) https://bugs.webkit.org/show_bug.cgi?id=91881 Reviewed by Oliver Hunt. Check to make sure that the value being retrieved is an object. This is similar to the isObject() check done in the bindings code. Test: fast/notifications/notifications-event-listener-crash.html * bindings/js/Dictionary.h: (WebCore::Dictionary::getEventListener): 2012-11-02 Lucas Forschler Merge r124588 2012-08-03 Adam Barth WebCore::DragController::cleanupAfterSystemDrag should null-check page https://bugs.webkit.org/show_bug.cgi?id=61815 Reviewed by Eric Seidel. * page/DragController.cpp: (WebCore::DragController::dragEnteredOrUpdated): (WebCore::DragController::doSystemDrag): 2012-11-02 Lucas Forschler Merge r124580 2012-08-03 Abhishek Arya Regression(r124564): Wrong inlineChildrenBlock->hasLayer() computed in RenderBlock::removeChild. https://bugs.webkit.org/show_bug.cgi?id=90800 Reviewed by Eric Seidel. r124564 reversed the sequence of setStyle and removeChildNode calls, but failed to cache the value of inlineChildrenBlock->hasLayer(). So, it will be null when the layer is removed from parent in setStyle. Fixed by the caching the bool value. Covered by existing test fast/block/layer-not-removed-from-parent-crash.html. * rendering/RenderBlock.cpp: (WebCore::RenderBlock::removeChild): 2012-11-02 Lucas Forschler Merge r124564 2012-08-02 Abhishek Arya Crash due to layer not removed from parent for anonymous block. https://bugs.webkit.org/show_bug.cgi?id=90800 Reviewed by Kent Tamura. Reverse the order of setStyle and removeChildNode calls. This ensures that setting the style properly removes its layer from the parent in RenderBoxModelObject::styleDidChange. Calling removeChildNode before calling setStyle is problematic since the parent layer never gets notified. Test: fast/block/layer-not-removed-from-parent-crash.html * rendering/RenderBlock.cpp: (WebCore::RenderBlock::removeChild): 2012-11-02 Lucas Forschler Merge r124556 2012-08-02 Kent Tamura Fix crashes for and