Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 157961 Display of CSS3 transformed area doesn't line up with hit-testing area
Starred by 3 users Reported by weilou.h...@gmail.com, Oct 25, 2012 Back to list
Status: Verified
Owner: shawnsingh@chromium.org
Closed: Feb 2013
Cc: vollick@chromium.org, shawnsingh@chromium.org, hartma...@chromium.org, mikelawther@chromium.org
Components:
OS: Windows
Pri: 2
Type: Bug


Sign in to add a comment
UserAgent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce the problem:
1. Access to http://weilou.me/videos/youtube/playlist-PL77E99D30B46BB0DB/video-ivzy3HEgrPo.
2. You will see a button "HD".

What is the expected behavior?

What went wrong?
Move your mouse over button "HD". You can't click on this button if your mouse is located at the left of letter "H".

Move your mouse to the right area of the playing video. And then click once. You find that you successfully click on the video. And the video is paused by you. This is wrong. Because you didn't click on the video. You just clicked on the right area of the video.

Move your mouse to one video thumbnail among all video thumbnails. If you click on thumbnail's left area which is near the left edge of thumbnail, This video thumbnail can't be clicked.

The video title located at the below of video thumbnail has the same bug.

When will this bug be fixed?

Example URL:
http://weilou.me/videos/youtube/playlist-PL77E99D30B46BB0DB/video-ivzy3HEgrPo

Does it occur on multiple sites: N/A

Is it a problem playing media? No

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes Firefox 16.0.1 on PC, IE10 on Windows 8, Safari 6 on Mac, Mobile Safari on iOS 6

Chrome version: 22.0.1229.94  Channel: n/a
OS Version: 6.0 (Windows Vista, Windows Server 2008)
 
Comment 1 by vfedorov@chromium.org, Oct 26, 2012
Labels: nomedia
Comment 2 by weilou.h...@gmail.com, Oct 26, 2012
What does "nomedia" mean?
Comment 3 by weilou.h...@gmail.com, Oct 26, 2012
What does "nomedia" stand for? This bug is needed to be confirmed and fixed.
Comment 4 by pavanv@chromium.org, Oct 27, 2012
Labels: -Area-Compat Area-WebKit Mstone-22 WebKit-CSS
Status: Untriaged
happens on latest stable 22.0.1229.76
Comment 5 by k...@google.com, Nov 5, 2012
Labels: -Mstone-22 MovedFrom-22 Mstone-25
Cleaning out 22.
Comment 6 by weilou.h...@gmail.com, Nov 22, 2012
The fix to this bug is needed! #Emergency
Cc: mikelawther@chromium.org
Labels: -WebKit-CSS Feature-GPU
Summary: CSS3 transformed area doesn't line up with hit-testing area (was: NULL)
Doesn't look like a problem WebCore's CSS. Using Inspector, the bounding boxes of where eg Inspector thinks the object should be be doesn't line up with what is rendered (see attached transform-chrome.png)

The problem does not repro in Safari (see attached transform-safari.png).

It seems to be a problem with the application of the transforms?
transform-safari.png
78.1 KB View Download
transform-chrome.png
127 KB View Download
Summary: Display of CSS3 transformed area doesn't line up with hit-testing area (was: NULL)
Comment 9 by vangelis@chromium.org, Nov 26, 2012
Cc: shawnsingh@chromium.org
It does look like the positioning of the element with the GPU compositor isn't quite right in Chrome.  
FYI a related issue may be http://code.google.com/p/chromium/issues/detail?id=126479

Based on the description here, though, it might not be a duplicate.
Please fix it.
Labels: -Mstone-25 Mstone-26
Owner: shawnsingh@chromium.org
Status: Assigned
Hi Weilou - apologies for the bad delay.  Due to our release cycle, the earliest this fix will appear is version 25 -- however, the cutoff point for us on version 25 is Dec 17th, and we are currently busy with some other important priorities.  So this may not get addressed by that time.

I'm taking ownership so that this doesnt get forgotten or lost.  I'll post an update when I start working on it. =)

Thanks for your patience.
Hi, shawnsingh. You're welcome. :)
The fix to this bug is expected to start. :)
I just filed a new Chromium bug 167505 (https://code.google.com/p/chromium/issues/detail?id=167505). I can't sure if these 2 Chromium bugs share the same Chromium's problem.
First round of debugging doesn't show any obvious incorrectness in our code.  I did notice that perspective in Safari seems to be rounded off, while chromium seems to be fractional pixel units.  This may be something we want to look at separately, but it seemed to me that it's not the cause of this problem.

So I'm still debugging. =)  I'll report when I have something more concrete.
Thank you! I appreciate your hard working.
Issue 167505 has been merged into this issue.
When will this bug be fixed?
I will try to have this fixed by m26.  The branch point for 26 is a few weeks away, and would probably reach stable approximately in March - http://dev.chromium.org/developers/calendar - I promise I haven't forgotten about this bug.
Thank you!
Cc: hartma...@chromium.org vollick@chromium.org
Update:

I did spend quite a lot of time looking at this, but unfortunately I wasn't able to solve it yet, to make the m26 branch.  Hopefully we can request tech leads to merge back to m26 once we have a fix.

At least, I do have a workaround for you, so you can get your website working correctly: move the button called "3D" outside of the "wrapper-2" perspective container.  It looks like you don't want it to be a 3d layer, anyway, right?  This should fix the problem for you.  This also explains the problem from bug 167505.

I have also attached a reduced test case.  The problem is that the extra absolute-positioned element will change the size and location of the perspective container, and as a result, then the "center" about which we apply the perspective is also changed.  I'm still confused about why Safari does not have a problem, though.  The shared code between Safari and Chrome in WebCore/rendering seems to be the same (and seems correct).  I don't see anything in the platform/graphics/ca/ code that indicates it handles perspective in any unique way, so I suspect that it's a detail of how core animation handles it, which is code I cannot see.

Also, according to spec, it does seem like we've implemented it correctly - I may be misunderstanding some details in the spec, though.

Please let me know if the workaround works for you.  Thanks again for your patience, we're all spread quite thin over here.
Ugh.... after all that crazy debugging and hard work - the fix is actually just 2 lines of code.   Hopefully fix will be in by tonight and make it into m26 after all.
Project Member Comment 24 by bugdroid1@chromium.org, Feb 12, 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=181957

------------------------------------------------------------------------
r181957 | shawnsingh@chromium.org | 2013-02-12T18:31:21.331144Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/layer_tree_host_common_unittest.cc?r1=181957&r2=181956&pathrev=181957
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/layer_tree_host_common.cc?r1=181957&r2=181956&pathrev=181957

[cc] Apply sublayer transform about anchor instead of about layer center.

There are some cases where WebCore internally needs to "reposition" the origin
point about which CSS transforms are applied. For example, when a perspective
container becomes composited, the composited location/bounds may change
depending on the positioning of its children. The perspective-origin from the
original DOM tree should not change, but internally it does require a new
origin to be given to the compositor. It turns out that WebCore uses the anchor
point layer property to communicate these cases. So, the compositor needs to
apply the sublayer transform about the anchor point instead of about the layer
center.

BUG= 157961 


Review URL: https://chromiumcodereview.appspot.com/12224113
------------------------------------------------------------------------
Labels: ReleaseBlock-Beta Merge-Requested
Requesting to merge this to m26.  This patch fixes a user-facing usability problem where hit testing does not match what the user sees.  Thanks in advance =)
Thank you very much for your hard works! I'm pleased to see the fix is in its way. I expect users can get this bug fix recently. Thanks again!
Comment 27 by tanyarad@google.com, Feb 15, 2013
Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Status: Fixed
Project Member Comment 29 by bugdroid1@chromium.org, Feb 15, 2013
Labels: merge-merged-1410
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=182808

------------------------------------------------------------------------
r182808 | shawnsingh@google.com | 2013-02-15T20:15:38.050069Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/cc/layer_tree_host_common_unittest.cc?r1=182808&r2=182807&pathrev=182808
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/cc/layer_tree_host_common.cc?r1=182808&r2=182807&pathrev=182808

Merge 181957
> [cc] Apply sublayer transform about anchor instead of about layer center.
> 
> There are some cases where WebCore internally needs to "reposition" the origin
> point about which CSS transforms are applied. For example, when a perspective
> container becomes composited, the composited location/bounds may change
> depending on the positioning of its children. The perspective-origin from the
> original DOM tree should not change, but internally it does require a new
> origin to be given to the compositor. It turns out that WebCore uses the anchor
> point layer property to communicate these cases. So, the compositor needs to
> apply the sublayer transform about the anchor point instead of about the layer
> center.
> 
> BUG= 157961 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/12224113

TBR=shawnsingh@chromium.org
Review URL: https://codereview.chromium.org/12278010
------------------------------------------------------------------------
Can anyone tell which Chrome's version will have this fix? Thank you.

Version 26.  In the meantime, you can refer to the workarounds I had proposed above, I think they will work. =)
Thank you for your reply! I got it.
Labels: TE-Verified-26.0.1410.10
Status: Verified
Tested this issue with 26.0.1410.10 on Win7 - Working as intended.

Thank you!
Project Member Comment 34 by bugdroid1@chromium.org, Mar 10, 2013
Labels: -Area-WebKit -Mstone-26 -Feature-GPU Cr-Content Cr-Internals-GPU M-26
Project Member Comment 35 by bugdroid1@chromium.org, Apr 5, 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment