Bug 245145 – REGRESSION (iOS 16): Sequences of strokes in canvas may stroke with incorrect styles

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: New Bugs

[Jason Merrill]

Created attachment 462322 [details]
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.

[Ahmad Saleem]

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!

[Radar WebKit Bug Importer]

<rdar://problem/99886849>

[Simon Fraser (smfr)]

Possibly regressed at https://commits.webkit.org/252522@main

[Chris Campbell]

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.

[Bogdan Zhavraev]

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/

[Alexey Proskuryakov]

*** Bug 245420 has been marked as a duplicate of this bug. ***

[Paul Neave]

(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();
```

[Bogdan Zhavraev]

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/)

[Alexey Proskuryakov]

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 ***