245145 2022-09-13 09:05:31 -0700 REGRESSION (iOS 16): Sequences of strokes in canvas may stroke with incorrect styles 2022-09-24 16:58:51 -0700 1 1 1 Unclassified WebKit New Bugs Safari Technology Preview All All RESOLVED DUPLICATE 245465 BrowserCompat, InRadar P1 Major --- 1 jwmerrill webkit-unassigned ahmad.saleem792 ap bfulgham ccampbell karlcow mattwoodrow paul.neave realer09 simon.fraser webkit-bug-importer zalan oldest_to_newest 1898261 0 462322 jwmerrill 2022-09-13 09:05:31 -0700 Created attachment 462322 Drawing two lines to canvas draws the second line with an incorrect stroke style In Safari 16, on macOS 12.6 and iOS 16 Beta, certain sequences of stroke calls using the CanvasRenderingContext2D API stroke paths with incorrect properties. This is a regression compared to Safari 15. The attached example strokes two single-segment paths. Before the first stroke call, the strokeStyle is set to #f00 (red). Before the second stroke call, the strokeStyle is set to #000 (black). In most browsers, the second path is correctly stroked black, but in Safari 16, both paths are stroked red. We have experimented with many minor variations of this problem. A few observations: * strokeStyle is not the only affected property. lineWidth suffers from similar problems, and other properties may be affected too. * The problem seems to depend on how many points are on the path. We have observed the problem with two point paths (i.e. single straight segments), but not with more complex paths. * The problem seems to depend on attempting to set drawing context properties back to previously used values. In the attached example, the problem occurs when we attempt to set strokeStyle back to its default value (#000). This update is not applied when the path is stroked, and instead, the previous strokeStyle (#f00) is used. * The problem seems to be affected by how clearRect calls are interleaved with stroke calls. Writes to strokeStyle or lineWidth (and perhaps other properties) appear not to be applied when they attempt to set a property back to the value it had at the time of the last clearRect call. * We have reproduced similar problems with no clearRect calls at all, so the problem appears to be influenced by clearRect, but does not depend on clearRect. We'd be happy to supply additional variations on the attached example if it would be helpful. The attached example is a reduced test case based on bugs reported to Desmos by iOS 16 Beta users using the Desmos Graphing Calculator (https://www.desmos.com/calculator). This bug report was jointly prepared by Jason Merrill and Julia Proft. 1898302 1 ahmad.saleem792 2022-09-13 12:05:46 -0700 I am able to reproduce this bug in Safari 16 / STP 153 on macOS 12.6 and also on iOS 16 while other browsers like Chrome Canary 107 and Firefox Nightly 106 render horizontal line in ‘black’ color rather than ‘red’. Thanks! 1898327 2 webkit-bug-importer 2022-09-13 13:43:51 -0700 <rdar://problem/99886849> 1898328 3 simon.fraser 2022-09-13 13:43:58 -0700 Possibly regressed at https://commits.webkit.org/252522@main 1898751 4 ccampbell 2022-09-15 10:57:11 -0700 I believe this bug report accurately describes the graph rendering issues we're seeing in the En-ROADS climate simulator: https://en-roads.climateinteractive.org/scenario.html The issue causes lines to appear with the wrong color (e.g., the "Baseline" plot should always be black, not gray) and/or with the wrong stroke width (hovering over the "Current Scenario" blue plot sometimes causes it to appear thin instead of thick). These issues were not present in Safari 15 or any other browser. Only reproducible in Safari 16.0, Safari 16.1 beta1, and latest Safari Technology Preview (Release 153). FWIW, we use Chart.js (https://github.com/chartjs/Chart.js) v2.9.4 for rendering graphs in En-ROADS. While I don't have a smaller test case that reproduces this outside of En-ROADS/Chart.js, I hope you'll use En-ROADS to verify the fix for this regression. 1899762 5 realer09 2022-09-20 03:22:39 -0700 Facing similar issue with Canvas not properly switching between stroke styles and line widths on Safari 16 (both MacOS and iOS). Hope my example helps to debug this issue. https://jsfiddle.net/387t6cem/1/ 1899990 6 ap 2022-09-20 18:36:49 -0700 *** Bug 245420 has been marked as a duplicate of this bug. *** 1900060 7 paul.neave 2022-09-21 01:15:34 -0700 (In reply to Simon Fraser (smfr) from comment #3) > Possibly regressed at https://commits.webkit.org/252522@main Yes it could be that the batch optimizations/caching introduced here is overaggressive and has not been tested for all cases. Until this is fixed, a hacky workaround is to adjust the lineWidth between each stroke to circumvent this 'caching' behavior. For example: ``` context.lineWidth = 6; context.beginPath(); context.strokeStyle = 'red'; context.moveTo(30, 50); context.lineTo(50, 50); context.stroke(); context.beginPath(); context.strokeStyle = 'blue'; context.moveTo(60, 50); context.lineTo(80, 50); context.stroke(); context.lineWidth = 6.001; // Small adjustment here or the next stroke will remain blue context.beginPath(); context.strokeStyle = 'red'; context.moveTo(90, 50); context.lineTo(110, 50); context.stroke(); ``` 1900082 8 realer09 2022-09-21 04:39:37 -0700 This workaround won't cover all bug cases. In my example, i'm always changing lineWidth along with strokeStyle, and yet bugs with invalid color or width are reproducible (https://jsfiddle.net/387t6cem/1/) 1900955 9 ap 2022-09-24 16:58:51 -0700 We currently consider this to be a dupe of bug 245465. Sorry for duping to a newer bug, but that one has a PR already posted. *** This bug has been marked as a duplicate of bug 245465 *** 462322 2022-09-13 09:05:31 -0700 2022-09-13 09:05:31 -0700 Drawing two lines to canvas draws the second line with an incorrect stroke style safari-16-draw-bug-stroke-style.html text/html 891 jwmerrill PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjaGFyc2V0PSJ1dGYtOCI+CiAg PG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRldmljZS13aWR0aCI+CiAgPHRp dGxlPlNhZmFyaSAxNiBjYW52YXMgYnVnIHN0cm9rZVN0eWxlPC90aXRsZT4KPC9oZWFkPgo8Ym9k eT4KICA8cD5UaGVyZSBzaG91bGQgYmUgYSBkaWFnb25hbCByZWQgbGluZSBhbmQgYSBob3Jpem9u dGFsIGJsYWNrIGxpbmUsIGJ1dCBpbiBTYWZhcmkgMTYsIGJvdGggbGluZXMgYXJlIHJlZC48L3A+ CiAgPHNjcmlwdD4KICAgIHZhciBjYW52YXMgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdjYW52 YXMnKTsKICAgIGRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoY2FudmFzKTsKICAgIHZhciBjdHgg PSBjYW52YXMuZ2V0Q29udGV4dCgnMmQnKTsKCiAgICB2YXIgd2lkdGggPSAzMDA7CiAgICB2YXIg aGVpZ2h0ID0gMzAwOwogICAgY2FudmFzLndpZHRoID0gd2lkdGg7CiAgICBjYW52YXMuaGVpZ2h0 ID0gaGVpZ2h0OwoKICAgIGN0eC5jbGVhclJlY3QoMCwgMCwgd2lkdGgsIGhlaWdodCk7CgogICAg Ly8gZHJhdyByZWQgbGluZQogICAgY3R4LnN0cm9rZVN0eWxlID0gIiNmMDAiOwogICAgY3R4LmJl Z2luUGF0aCgpOwogICAgY3R4Lm1vdmVUbygwLCAwKTsKICAgIGN0eC5saW5lVG8od2lkdGgsIGhl aWdodCk7CiAgICBjdHguc3Ryb2tlKCk7CgogICAgLy8gZHJhdyBibGFjayBsaW5lCiAgICBjdHgu c3Ryb2tlU3R5bGUgPSAiIzAwMCI7CiAgICBjdHguYmVnaW5QYXRoKCk7CiAgICBjdHgubW92ZVRv KDAsIGhlaWdodC8yKTsKICAgIGN0eC5saW5lVG8od2lkdGgsIGhlaWdodC8yKTsKICAgIGN0eC5z dHJva2UoKTsKICA8L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+