1500137 - Weird UI on hacktoberfest progress check page (due to grid item growing to fit the <canvas>, unlike Chrome / WebKit and Edge)

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect, P3)

Description

[Cheng-You Bai [:cybai] UTC+9]

Attachment: Screen Shot 2018-10-18 at 11.13.09 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Check https://hacktoberfest.digitalocean.com/ for personal progress

(In the attachment, left is in Firefox Nightly, right is in Chrome)




Actual results:

The progress circle canvas is too big and it's also overlapped by the repo names.


Expected results:

The progress circle canvas should be beside the repo names.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

So, I took a look at this, and I can repro it. The canvas has width="800" and height="800", while chrome has width="406" and same height.

I don't know what's going on, but debugging a bit I could see that the bogus canvas width is set from:

  https://github.com/chartjs/Chart.js/blob/3830216420d7f85ed4a037bfb3bc7be1d7e70512/src/core/core.helpers.js#L527

I've also verified that devicePixelRatio is 2, as expected in my HiDPI screen, so I'm not sure why Chrome _isn't_ getting the same bogus scaling.

You can see the bug in action in the following URL:

  https://hacktoberfest.digitalocean.com/stats/emilio

(I registered because I thought you had to be registered to see your stats, but apparently they're public).

Mike, do you know if we have similar webcompat.com bugs related to Chart.js?

Comment 2

[Mike Taylor [:miketaylr]]

I don't see anything for chartjs in our web-bugs repo...

Probably also worth looking into this "resize-monitor" https://github.com/chartjs/Chart.js/blob/da3aa68f38b9db25156c3b32c56098f9ca70f4d8/src/platforms/platform.dom.js#L168

Poking around now.

Comment 3

[Mike Taylor [:miketaylr]]

Looks like this is configured here: https://www.chartjs.org/docs/latest/general/responsive.html

Comment 4

[Mike Taylor [:miketaylr]]

If I remove the scroll event handles from .chartjs-size-monitor-expand and .chartjs-size-monitor-shrink in Chrome, resizing similarly stops working. Possibly related?

Those are here:

https://github.com/chartjs/Chart.js/blob/da3aa68f38b9db25156c3b32c56098f9ca70f4d8/src/platforms/platform.dom.js#L209-L221

This resizer code is based on the following repo, which does have a related issue:

https://github.com/marcj/css-element-queries/pull/109

Any of that jump out at you, Emilio?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case that reproduces based on one of the repo examples.

On a HiDPI display, they scale the canvas up, then try to measure the available size, which in Firefox grows, but in Chrome does not.

This is a grid interop issue afaics, not sure if the grid item should grow or not.

Will build a testcase without a chart and see what Mats thinks about it.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase that shows the difference.

In Firefox, the second grid item grows to fit the image, in Chrome it doesn't, so they happen to end up measuring the right size and shrinking the doughnut, while in Firefox they do not.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Mats, any chance you can take a look at the testcase in comment 6 and tell who's right? :)

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Edge also agrees with Chrome and WebKit on this one, fwiw.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Workaround would be to set something like max-width: 100% or the grid item...

Comment 10

[Manuel Rego Casasnovas]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)
> Created attachment 9018390 [details]
> Testcase that shows the difference.
> 
> In Firefox, the second grid item grows to fit the image, in Chrome it
> doesn't, so they happen to end up measuring the right size and shrinking the
> doughnut, while in Firefox they do not.

This is reproducible with a smaller example even without images:
  <div style="display: grid; grid-template-columns: repeat(4, 1fr); width: 100px; border: solid;">
    <div style="background: cyan; grid-column: span 2;">This_is_a_very_long_line!</div>
  </div>

I believe the issue here is that the grid item is not getting shrinked
(due to "justify-self: stretch") to the size of the columns.
The size of the columns is the same in all browsers
(900px / 12 = 75px in Emilio's example, 100px / 4 = 25px in mine).

In Chromium if you use "justify-self: start",
the output is the same than in Firefox.
I don't find a good reason why this shouldn't get shrinked.

Comment 11

[Mats Palmgren (inactive)]

Grid items has "min-width: auto" as the initial value, which is
specified in:  https://drafts.csswg.org/css-grid/#min-size-auto
The first two bullets in that list do not apply.
"Content size suggestion" says "The content size suggestion is
the *min-content size* in the relevant axis" which is defined as 
"The narrowest inline size a box could take that doesn’t lead to
inline-dimension overflow that could be avoided by choosing a larger
inline size. Roughly, the inline size that would fit around its
contents if all soft wrap opportunities within the box were taken."
https://drafts.csswg.org/css-sizing-3/#min-content
The text "This_is_a_very_long_line!" does not have any soft wrap
opportunities so the "content size suggestion" is the inline-size
of the text (plus any padding/border/margin).  So the used min-width
value for the grid item is the width of its text.

https://drafts.csswg.org/css-align-3/#justify-self-property
"'stretch': ... sets the box’s used size to the length necessary
to make its outer size as close to filling the alignment container
as possible while still respecting the constraints imposed by
min-height/min-width/max-height/max-width."
Please note the latter part of that sentence - the item should NOT
shrink below its min-width.

So, this looks like a bug in Chrome to me.

(Fwiw, if I add "min-width: 0" to the grid item then we it render
it as in Chrome.  And if you set "min-width: min-content" then
Chrome renders it as in Firefox.)

Rego, do you agree with the above analysis, or did I miss
something in the specs?

Comment 12

[Mats Palmgren (inactive)]

... well, strike out " (plus any padding/border/margin)".  That was
a mistake since we're talking about content-box sizes here.

Comment 13

[Mike Taylor [:miketaylr]]

(i sent an email to the contact address on the hacktoberfest page, with details for the workaround)

Comment 14

[Manuel Rego Casasnovas]

Yes I agree this is a bug on Chromium, I didn't realize about that.
I've reported https://bugs.chromium.org/p/chromium/issues/detail?id=899720

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Moving to Tech Evangelism then.

Comment 16

[Mike Taylor [:miketaylr]]

The site has been archived -- "We'll see you next October!", so I guess I'll close this now. Unsure if they ever implemented the workaround... so I'll just close as INVALID (valid bug, just not on this site anymore).

Thanks for filing the crbug though.