Bug 242629
Summary: | atan2 calc() function behaves incorrectly with different units | ||
---|---|---|---|
Product: | WebKit | Reporter: | Devon Govett <govett> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | 50167214, ahmad.saleem792, ap, bfulgham, karlcow, koivisto, nmouchtaris, ntim, simon.fraser, webkit-bug-importer, zalan |
Priority: | P2 | Keywords: | GoodFirstBug, InRadar |
Version: | Safari 15 | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Devon Govett
The atan2 function in CSS accepts dimensions, percentages, or numbers as inputs as long as the two arguments have the same type. However, the matching type doesn't mean the values are of the same units. As discussed in https://github.com/w3c/csswg-drafts/issues/7482, WebKit's current implementation behaves incorrectly when the units differ.
For example, currently the following behave identically:
```
rotate: atan2(90px, 90px);
rotate: atan2(90px, 90vw);
```
However, `90vw` should be resolved at computed value time and used rather than ignoring the unit completely. The same is true for examples like the following, where a computation includes incompatible units:
```
rotate: atan2(90px, 10px + 10vw);
```
Currently, WebKit ignores the 10vw completely here, and behaves the same as atan2(90px, 10px). The computation should be resolved and the result should be based on whatever 10px + 10vw computes to.
The current tests in web platform tests don't include any examples of differing units, but probably should.
Here's a codepen where you can see how WebKit currently renders some examples. https://codepen.io/devongovett/pen/GRxqNYj
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/97235085>
Ahmad Saleem
All three browsers differ in the attached test case (CodePen) from Comment 0.
*** Safari Technology Preview 152 on macOS 12.5.1 ***
Two Tilted red square first then in the last square
*** Chrome Canary 107 ***
Three red square
*** Firefox Nightly 106 ***
Titled red square and then simple square and then again tiled red square.
______
Just wanted to share updated results. Thanks!
Ahmad Saleem
Chrome Canary 117 and WebKit ToT (266719@main) seems to match each other while Firefox Nightly 118 is different from other.
Do we need to do anything here? CCing @Tim - since he fixed similar bugs recently.
Tim Nguyen (:ntim)
(In reply to Ahmad Saleem from comment #3)
> Chrome Canary 117 and WebKit ToT (266719@main) seems to match each other
> while Firefox Nightly 118 is different from other.
>
> Do we need to do anything here? CCing @Tim - since he fixed similar bugs
> recently.
WebKit & Chrome still have an incorrect result here, since the first 2 squares are identical (first one uses 90px, second uses 90vw).
They should defer computation to computed-value time.
Arguably Firefox is slightly more correct here by rejecting the computation altogether (instead of computing to something incorrect), but that's not what the spec wants.
Tim Nguyen (:ntim)
*** This bug has been marked as a duplicate of bug 278244 ***
yisibl
Looks like Chrome 132 is wrong in the second test case? It seems to resolve to `atan2(5px, 5px)`.
```css
#b {
rotate: atan2(5px, 5vw);
}
```
Karl Dubost
Also relevant https://github.com/w3c/csswg-drafts/issues/8169