Use outlineBox if we have an outline or shadow

Source/core/rendering/RenderBlock.cpp

Index: Source/core/rendering/RenderBlock.cpp
diff --git a/Source/core/rendering/RenderBlock.cpp b/Source/core/rendering/RenderBlock.cpp
index e500831f7515f4f71dc455f70006eede52b534cb..504ee233abcdfa9ec66e65cc4a27b7eabbafeb95 100644
--- a/Source/core/rendering/RenderBlock.cpp
+++ b/Source/core/rendering/RenderBlock.cpp
@@ -1731,7 +1731,7 @@ LayoutUnit RenderBlock::marginIntrinsicLogicalWidthForChild(RenderBox* child) co
     return margin;
 }
 
-void RenderBlock::layoutPositionedObjects(bool relayoutChildren, bool fixedPositionObjectsOnly)
+void RenderBlock::layoutPositionedObjects(bool relayoutChildren, bool fixedPositionObjectsOnly, bool parentMoved)

[Julien - ping for review, 2014/03/07 00:01:10]

s/parent/containingBlock/ (positioned object is the reason why we talk about
containing blocks and not parents :))

[dsinclair, 2014/03/07 03:18:56]

Done.

 {
     TrackedRendererListHashSet* positionedDescendants = positionedObjects();
     if (!positionedDescendants)
@@ -1786,6 +1786,9 @@ void RenderBlock::layoutPositionedObjects(bool relayoutChildren, bool fixedPosit
             oldLogicalTop = logicalTopForChild(r);
         }
 
+        if (parentMoved)
+            r->setNeedsLayout();

[Julien - ping for review, 2014/03/07 00:01:10]

Is this guaranteed to work? We only ensure that the positioned objects that are
under |this| get repainted, not the whole positioned hierarchy, which is what we
would need (logicalLeft is the offset from your containing block which has only
changed for the renderer being shifted)

Also shouldn't this be setNeedsPositionedMovementLayout() for the case you're
interested in?

[dsinclair, 2014/03/07 03:18:56]

I don't know? This seemed to work for the test case I have, not sure if there
are other cases that need to be handled in here as well.
If I do r->setNeedsPositionedMovementLayout() here it doesn't seem to cause the
invalidation. Having it as setNeedsLayout() does trigger the invalidation. Is
there something else I'm missing?.

[Julien - ping for review, 2014/03/08 01:26:53]

The whole positioned hierarchy is shifted in this case but we only ever force an
invalidation for the direct positioned descendant. We talked about some cases I
thought would defeat this but they worked which makes me wonder if something
else is not generating invalidations.
That's weird, maybe a full layout forces the descendants to be invalidated. I
would rather have this understood and investigated as this will definitely bite
us down the road. I could live with a FIXME with a blocking bug on RAL but only
if this blocks something.

[dsinclair, 2014/03/10 00:22:51]

Done.

crbug.com/350756  I didn't mark the bug as blocking RAL as I don't think it
blocks anything at the moment?

+
         r->layoutIfNeeded();
 
         // Lay out again if our estimate was wrong.