New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 803824 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Calc function in sizes attribute doesn't work correctly (probably operator precendence problem)

Reported by radek.s...@gmail.com, Jan 19 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. Navigate to https://codepen.io/anon/pen/GyPymY?editors=1100#0
2. Change window size to something between 1000px and 1400px
3. Reload the page.

What is the expected behavior?
All three images should use the same image size (430x330) as mathematically, all expressions in calc functions are equivalent.

What went wrong?
The first image is loaded in bigger resolution than necessary. It should have loaded 430x330 as well, but loaded 645x495. Only difference are omitted parentheses in calc expression around multiplication.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by woxxom@gmail.com, Jan 19 2018

Bisect info: 323259 (good) - 323271 (bad)
https://chromium.googlesource.com/chromium/src/+log/70737eee..9a186f77?pretty=fuller
In r323264 "WebKit roll" suspecting 390858b22f2f453a68a2e56150a0f255e61a1c96
"Avoid srcset upscaling for 1x DPR scenarios"
https://crrev.com/1045353002
Landed in 43.0.2354.0

Repro note: drag the right window border to resize the window between 1000px and 1400px - in good builds the first image doesn't change, in bad builds it alternates between 430x300 and 645x495.
Cc: vamshi.k...@techmahindra.com
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable Triaged-ET M-66 hasbisect OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: y...@yoav.ws
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on reported chrome version 63.0.3239.132 and on the latest canary 66.0.3327.0 using Mac 10.13.1 , Windows 10 and Ubuntu 14.04.
As per comment#1 suspecting the same i.e., Change log: https://chromium.googlesource.com/chromium/src/+log/70737eee..9a186f77?pretty=fuller and Suspecting https://chromium.googlesource.com/chromium/blink/+/390858b22f2f453a68a2e56150a0f255e61a1c96
Review URL: https://codereview.chromium.org/1045353002

@yoav@yoav: Please feel free to re-assign if it is not related to your change.

Adding RB-Stable, Please feel free to remove if it is not applicable.

Thanks!
Labels: FoundIn-66 Target-66 FoundIn-65

Comment 4 by y...@yoav.ws, Jan 22 2018

Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
I don't know if it's related to that change (I'll have to take a deeper look), but according to your bisect, this issue has been around for 23 (!!!) Chrome releases and almost 3 years. Any particular reason you think this should be is a P1 ReleaseBlocker-Stable?
Components: Blink>Image Blink>Layout
Cc: y...@yoav.ws
Components: -Blink>Image -Blink>Layout Blink>CSS
Owner: ----
Status: Untriaged (was: Assigned)
That blame is almost certainly due to something changing the image behavior that revealed the calc problem. Isn't calc a CSS thing?
Cc: -y...@yoav.ws
Components: -Blink>CSS Blink>Image
Owner: y...@yoav.ws
Status: Assigned (was: Untriaged)
But in any event, yoav@, could you check the chain of values going into the image selection to see where it goes wrong (i.e the CSS or the length resolution or what)?
Labels: -Type-Bug-Regression Type-Bug

Comment 9 by f...@opera.com, Jan 26 2018

Cc: y...@yoav.ws
Owner: f...@opera.com
Status: Started (was: Assigned)
There does indeed appear to be an operator precedence issue in the 'sizes' calc() parser. Should have a fix shortly.
Project Member

Comment 10 by bugdroid1@chromium.org, Jan 27 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0bcd910832c55445bc6bb4156acd716e0667248

commit e0bcd910832c55445bc6bb4156acd716e0667248
Author: Fredrik Söderquist <fs@opera.com>
Date: Sat Jan 27 00:31:36 2018

Fix operator precedence in SizesCalcParser

Pop all operators with greater/equal precedence rather than just the
top-most.

Bug:  803824 
Change-Id: I5f106a0e82ed98ba2510c86ed157bf4b133cb5b8
Reviewed-on: https://chromium-review.googlesource.com/888919
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Yoav Weiss <yoav@yoav.ws>
Cr-Commit-Position: refs/heads/master@{#532100}
[modify] https://crrev.com/e0bcd910832c55445bc6bb4156acd716e0667248/third_party/WebKit/Source/core/css/parser/SizesCalcParser.cpp
[modify] https://crrev.com/e0bcd910832c55445bc6bb4156acd716e0667248/third_party/WebKit/Source/core/css/parser/SizesCalcParserTest.cpp

Comment 11 by f...@opera.com, Jan 27 2018

Status: Fixed (was: Started)
Operator precedence issue fixed - I'm not ruling out that there might be a image selection issue, but it seems better to handle that in a different bug if so.

Sign in to add a comment