1904969 - calc() that contains vw unit gives incorrect value while that with cqw unit works fine

Status: RESOLVED DUPLICATE of bug 1764768

(Core :: CSS Parsing and Computation, defect)

Description

[Barun Kharel]

Attachment: test-vw-css-unit.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

1. Open the attached HTML file
   There are two boxes in the HTML. The key difference is that the top box has following:
   width: calc(550 / 900 * 100vw);
   border: calc(2 / 900 * 100vw) solid;
   while the bottom box has following:
   width: calc(550 / 900 * 100cqw);
   border: calc(2 / 900 * 100cqw) solid;

2. Open Responsive Design Mode (Ctrl + Shift + M)

3. Set width of the viewport to 900

4. Check value of width and border-top-width properties of both boxes

5. Reduce width of the viewport by 1px at a time upto 896

Actual results:

When the viewport width = 900:

• width of top box = 549.983px
• width of bottom box = 550px
• border-top-width of top = border-top-width of bottom = 2px

When the viewport width = 899:

• width of top box = width of bottom box = 549.383px
• border-top-width of top box = 1px
• border-top-width of bottom box = 2px.

When the viewport width = 898:

• width of top box = 548.767px
• width of bottom box = 548.783px
• border-top-width of top box = 1px
• border-top-width of bottom box = 2px.

When the viewport width = 897:

• width of top box = 548.15px
• width of bottom box = 548.167px
• border-top-width of top box = 1px
• border-top-width of bottom box = 2px.

When the viewport width = 896:

• width of top box = width of bottom box = 547.55px
• border-top-width of top box = border-top-width of bottom box = 1px

(I have also tested in Firefox 128 Developer Edition and results are same.)

Expected results:

When viewport width = 900,
calc(550 / 900 * 100vw) in top box should give exactly 550px without decimal point similar to calc(550 / 900 * 100cqw) in bottom box

When viewport width is less than or equal to 900, 100vw is same as 100cqw in bottom box and therefore the value of width and border-top-width properties should be same for both boxes.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I think what you're seeing is that the viewport width isn't exactly a fixed number of pixels, but for legacy reasons innerWidth / innerHeight are rounded, see https://github.com/w3c/csswg-drafts/issues/5260

Comment 3

[Barun Kharel]

Attachment: Screenshot from 2024-07-12 20-33-23.png

This screenshot attachment shows how the HTML file looks in Firefox 128 (left) and Chrome 126 (right) when viewport is 900px wide.

Just to be clear, my PC has Device Pixel Ratio of 1. And, I think rounding should not cause any issue in device with DPR 1.

Also, I have shown those values in UI using JavaScript for ease of understanding. If there is rounding problem in JavaScript, you can also check the dimension in Web Developer Tools > Inspector tab.

My expectation is that vw and cqw should give same result whenever viewport and container have same width (as in Chrome).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Ah, I see what's going on. What happens is that you're hitting this code, while container queries don't do that "round to app units" here.

So it's a bit tricky because we want subpixel... I tried to fix that in bug 1764768, though stuff has changed since a bit, so I can try to re-land / fix it in some other way...

Let's close as a dupe of bug 1764768, will change that bug's title to reflect the root cause better.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I attached a patch in bug 1764768 which seems to not regress anything locally. Let's see how it fares on automation, but I'm hopeful :)

Comment 6

[Barun Kharel]

Although I don't understand the rust source code, I am glad that you were able to find the source of bug and make necessary changes.

Let's hope this inconsistency goes away in future release.