Bug 267986

Summary: Canvas with relative width not re-drawn correctly on parent resize
Product: WebKit Reporter: nicolo.ribaudo
Component: CanvasAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: dino, heycam, sabouhallawa, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 17   
Hardware: All   
OS: Unspecified   
Attachments:
Description Flags
index.html
none
PDF.js zoom tearing on Safari on desktop
none
Reproduction screenshot before setTimeout triggers
none
Reproduction screenshot after resizing the canvas parent
none
Reproduction screenshot after resizing the canvas parent, with initial width of 1024px none

nicolo.ribaudo
Reported 2024-01-24 00:59:06 PST
Created attachment 469524 [details] index.html When a canvas had `width: 100%` and the parent gets resized, the canvas gets resized accordingly. However, WebKit only redraws part of the resized canvas contents, leaving the rest with the old size. This bug affects all platforms and is easily noticeable on iPhone/iPad by using "pinch to zoom" with the popular PDF viewer [pdf.js](https://mozilla.github.io/pdf.js/): you can try it at https://mozilla.github.io/pdf.js/web/viewer.html. Past some zoom size (around 170% on iPad Air, and 200% on MacBook Air), the canvas where the PDF is rendered starts breaking into pieces. I created a minimal reproduction that works on an iPad Air 2022. There are many hard-coded number that seem to be very much device-specific, so the same reproduction doesn't show the bug on a MacBook Air (not even if I use Safari's Responsive Design Mode to emulate the iPad display size). I'm attaching the HTML file that shows the bug. I don't seem to be able to attach more than one file -- I'll post screenshots in a comment.
Attachments
index.html (1.38 KB, text/plain)
2024-01-24 00:59 PST, nicolo.ribaudo
no flags
PDF.js zoom tearing on Safari on desktop (1.23 MB, image/png)
2024-01-24 01:10 PST, nicolo.ribaudo
no flags
Reproduction screenshot before setTimeout triggers (3.33 MB, image/png)
2024-01-24 01:12 PST, nicolo.ribaudo
no flags
Reproduction screenshot after resizing the canvas parent (3.29 MB, image/png)
2024-01-24 01:13 PST, nicolo.ribaudo
no flags
Reproduction screenshot after resizing the canvas parent, with initial width of 1024px (3.14 MB, image/png)
2024-01-24 01:16 PST, nicolo.ribaudo
no flags
nicolo.ribaudo
Comment 1 2024-01-24 01:10:31 PST
Created attachment 469525 [details] PDF.js zoom tearing on Safari on desktop
nicolo.ribaudo
Comment 2 2024-01-24 01:12:07 PST
Created attachment 469526 [details] Reproduction screenshot before setTimeout triggers
nicolo.ribaudo
Comment 3 2024-01-24 01:13:35 PST
Created attachment 469527 [details] Reproduction screenshot after resizing the canvas parent
nicolo.ribaudo
Comment 4 2024-01-24 01:16:42 PST
Created attachment 469528 [details] Reproduction screenshot after resizing the canvas parent, with initial width of 1024px I also noticed that if the initial width of the canvas container is slightly larger (starting fro 1024px, rather than 1000px) the canvas is still re-rendered incorrectly but in a different way: only the new area is redrawn, and the original one is left untouched.
nicolo.ribaudo
Comment 5 2024-01-24 01:17:37 PST
Oh, and I also noticed that setting an explicit width on the canvas rather than a relative one fixes the rendering bug. Even just `width: inherit` is enough to get the canvas properly drawn, which is a good workaround for when trying to use `width: 100%`.
Radar WebKit Bug Importer
Comment 6 2024-01-31 01:00:16 PST
Note You need to log in before you can comment on or make changes to this bug.