Visual and clickable area on an element with clip-path don't match up when zoomed
Reported by
merlinlu...@yahoo.de,
Oct 24 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Open the attached file in chrome 2. Zoom in, say 500% 3. Move your mouse over the triangle 4. Try to find the actually clickable area on the top left corner somewhere, the same area as where the cursor changes to the correct text style What is the expected behavior? The expected behavior is that of Firefox, where the clickable area and the cursor style change match up with what you see drawn on the page. Note that the text can be selected correctly though. What went wrong? When zoomed in or out on a page with an element that has a clip-path, the area to click on the element does not match up with what you see drawn on the page. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Oct 25 2017
Forgot to mention: 1. This is still a bug in Chrome version 64 Canary. 2. The file in the OP got an onclick alert on the triangle, so clicking on the element should give an alert. The actual area where it gets registered as a click on the element is marked in red in the image included in this comment. It is somewhat the original size of the triangle with some offset and therefore doesn't match up on zoom levels other than 100%. 3. I would like to have the click registered when I click on where the element is actually drawn.
,
Oct 25 2017
Able to reproduce this issue on reported version 61.0.3163.100, latest stable 62.0.3202.62 and latest canary 64.0.3248.2 using Win 7, Win 10 , Ubuntu 14.04 and mac 10.12.6. In the older versions prior to M-55, the clip is seen as square and click is registered. However from M-55 the issue is seen as on latest, hence considering the issue as Non-Regression and marking it as Untriaged
,
Mar 23 2018
This issue should be marked as fixed, as it is the same as fixed issue 800605 . (https://bugs.chromium.org/p/chromium/issues/detail?id=800605) What I checked to confirm this: Issue 800605 was applied in snapshot 528743. It did not work correctly in snapshot 528732, but in 528751. It works since some version of version 65.0.3319.0, as well as my current stable channel version 65.0.3325.181 and canary 67.0.3378.0, all checked on Windows 7.
,
Nov 21
*** UI Mass Triage *** As per c#4 closing this issue.If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ligim...@chromium.org
, Oct 24 2017