Fix hover area for divs with css transforms

Fix hover area for divs with css transforms

The problem is that a rotated div doesn't trigger the :hover state (or
the onclick javascript handler) when the Z coordinate is negative at the
location of the mouse.

Non transformed layers are now being hit last, not through or in-between
transformed layers.
The paint order says that the divs creating stacking contexts (including
transforms) are painted after the other siblings so they should be hit
tested in the reverse order. Also, a rotated div in a non-rotated parent
should be hit in its entire area, not hit its parent's background, even
if the z-coordinate is negative where the mouse is located.

BUG=321959

[Mihai Maerean, 2013-11-21 16:21:21]

Please review changes

[eae, 2013-11-21 19:36:46]

https://codereview.chromium.org/81153002/diff/1/Source/core/rendering/RenderL...
File Source/core/rendering/RenderLayer.cpp (right):

https://codereview.chromium.org/81153002/diff/1/Source/core/rendering/RenderL...
Source/core/rendering/RenderLayer.cpp:2738: return
-std::numeric_limits<int>::max();
Shouldn't this be std::numeric_limits<int>::min() or LayoutUnit::min()?

[shawnsingh, 2013-11-21 20:47:39]

Mihai - can you please check if the problems you are seeing are fixed by this
patch instead - https://codereview.chromium.org/79943002/

I briefly tested it locally and I believe that fix is "more correct" than this
one.

The problem is that we need to distinguish whether a layer is in a "3d rendering
context" or not (i.e. the preserve3d property).  If layers are not in a 3d
rendering context, it doesn't matter (well - it _shouldn't_ matter) what the
value of the zOffset is returned here.  If layers are in a 3d rendering context,
I believe returning 0 is correct, and layers position with negative z values
should actually be considered behind the un-transformed layer.

Am I overlooking something about how this code works?

[Mihai Maerean, 2013-11-21 21:48:59]

On 2013/11/21 20:47:39, shawnsingh wrote:
> Mihai - can you please check if the problems you are seeing are fixed by this
> patch instead - https://codereview.chromium.org/79943002/

The patch you mentioned also passes the layout test in my patch.

> I briefly tested it locally and I believe that fix is "more correct" than this
> one.
> 
> The problem is that we need to distinguish whether a layer is in a "3d
rendering
> context" or not (i.e. the preserve3d property).  If layers are not in a 3d
> rendering context, it doesn't matter (well - it _shouldn't_ matter) what the
> value of the zOffset is returned here.  If layers are in a 3d rendering
context,
> I believe returning 0 is correct, and layers position with negative z values
> should actually be considered behind the un-transformed layer.
> 
> Am I overlooking something about how this code works?

Because of the painting order, the transformed div is painted after (and over)
its non transformed siblings (that are placed before and after it in the parent
element's DOM).
<div id="parent">
<div id="siblingbefore">sibling before</div>
<div id="transformed">transformed</div>
<div id="siblingafter">sibling after</div>
</div>

Both patches perform the hit test in the same way, the :hover state is activated
for #transformed on its entire surface (which is consistent with what's being
rendered).

From your comment, I understand that you would expect the other patch to behave
differently than it does.

I'll try to imagine a test that will make one of the patches to fail in order to
determine which one to keep.

[Mihai Maerean, 2013-11-22 16:20:23]

I have added a layout test that fails with this approach.
It happens with this DOM tree:
<div id="parent">
	<div id="transformed">transformed
		<div id="child1">child 1</div>
		<div id="nonTransformedChild">non transformed child</div>
		<div id="child2">child 2</div>
	</div>
</div>

child1 and child2 are transformed and rendered on top of the
nonTransformedChild, but the hit testing doesn't hit the layers that are on top
(child1 & child2).

This new layout test (hover-rotated-with-children-negative-z.html) should be
added to the other patch (at https://codereview.chromium.org/79943002/)