DevRel-SAP: Canvas rendering in hardware-accelerated context offset by scrollbar width
Reported by
dominic....@sap.com,
Jan 19 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: See the attached file to reproduce the problem. System: - Chrome Version 55.0.2883.87 m (64-bit) - OS: Windows 10 Enterprise (1607) What's done: - enable RTL mode via <dir="rtl"> or <direction: rtl> - have the parent element overflow vertically --> scrollbar becomes visible - transform: translate3d(0, 0, 0) the parent element - get the 2D context of the canvas - draw some lines that exceed some certain point the dimensions cannot be determined, but tests have shown that with a 164x74px canvas size, the drawn elements have to exceed 120px in width - the drawn element has to be filled (via context.fill) twice I am not sure about the steps leading to the issue. Maybe all these numbers are just a coincidence, but there certainly is something wrong with the canvas element. What is the expected behavior? What went wrong? The rendered content is shifted to the right by exactly the left scrollbar's width. This can especially be seen if the canvas's parent has a background color. Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 The following issue is similar: https://bugs.chromium.org/p/chromium/issues/detail?id=556043
,
Jan 19 2017
I am able to reproduce the issue on latest Chrome stable and older stable channels as well i.e., 53.0.2785.101, 54.0.2840.99. Note : Based on the other bug which was provided in bug report the bug is present for quite a longtime. skobes@ and szager@ can you please provide you insights.
,
Jan 19 2017
Since the bug is present for quite a long time I am punting the bug to M58, Please correct me if I misjudged the bug.
,
Jan 20 2017
,
Jan 25 2017
,
Jun 6 2017
Thanks for having a look at this issue! I saw that the related issue has been marked as fixed. So does this mean that we can regard this issue as fixed, too? I checked it with Chrome 59.0.3071.86 (Official Build) (64-bit) and the issue is still reproducible. Hope you can help.
,
Oct 18 2017
,
Oct 20 2017
I'm not sure I understand what's going wrong. Are you saying that the canvas element itself is on the wrong place, or that the drawn lines are in the wrong place? Attached is a screen shot of the reproduction. Does this look correct?
,
Oct 23 2017
I wasn't quite sure what was the cause, but the entire canvas was shifted when I tried drawing past a certain point inside the canvas. Retesting it with the newest version of chrome, I could no longer reproduce this error, so I guess this must have been fixed in another bug report. Thanks anyways for your support! The screenshot you attached looks correct. :) |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dominic....@sap.com
, Jan 19 2017