1761651 - A graphical glitch on Tom's Hardware

Status: RESOLVED DUPLICATE of bug 1886293

(Web Compatibility :: Site Reports, defect)

Description

[jin8864y]

Attachment: Tomshardware.JPG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

I was browsing https://www.tomshardware.com/

Actual results:

The top menu bar isn't displayed properly.

Expected results:

I wasn't navigate easily with that.

Comment 1

[Blake]

I couldn't narrow this down too much through mozregression

Last known good build: 2021-03-22
First known bad build: 2021-03-23

app_name: firefox
build_date: 2021-03-23
build_file: C:\Users%username%.mozilla\mozregression\persist\2021-03-23--mozilla-central--firefox-89.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2021/03/2021-03-23-21-43-59-mozilla-central/firefox-89.0a1.en-US.win64.zip
changeset: ea38e210ba4d6d14f40cd17fc38515ce7e965e60
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f5fd13efa844156d6de1ab4bf36ffbeeaf5bc425&tochange=ea38e210ba4d6d14f40cd17fc38515ce7e965e60
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e17c6f92b2bf41e464bbbea1afbff9c9e78db93b&tochange=94323c03b3da46afb965744af83cb6acfa92fc63

Comment 3

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

:TYLin, since you are the author of the regressor, bug 1697349, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Alice0775 White]

The scrollbar also appear in Chrome99, but it is styling.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Alice0775 White from comment #4)

The scrollbar also appear in Chrome99

Confirmed, I see this in Chrome 99 (tested on Windows) and in Chrome 101 dev (tested on Linux)

but it is styling.

By this I think you mean "it's styled to look nice", i.e. it's more subtle -- it just looks like a red bar there. That comes from this styling:

.trending__items::-webkit-scrollbar {
    background-color: var(--trending-scrollbar-background-color);
    height: 6px;
}
.trending__items::-webkit-scrollbar-thumb {
    background-color: var(--trending-scrollbar-color);
    border-radius: 10px;
}

If I uncheck those lines in devtools to disable those styles, then Chrome looks exactly like Firefox does in the attached screenshot (ugly scrollbar, partially covering up the content).

So:
(1) The fact that a scrollbar started appearing here is an expected outcome of the fact that we're now required by the spec to add some additional space influence the scrollable area of a scrollable flex container (per bug 1697349), and this makes us interoperable with Chrome on this point.

(2) The fact that Chrome looks nicer than us here is from the fact that they're honoring -webkit-scrollbar styles which is non-standard and which we don't support per https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-scrollbar / https://caniuse.com/?search=webkit-scrollbar

So: the issue here is a bug in the site (the fact that they use styles that [per up-to-date specs] create scrollable area and hence a scrollbar, and then they prettify/shrink that scrollbar in a WebKit-prefixed way.

--> Reclassifying as Web Compatibility; we could suggest that they style this scrollbar with the standard scrollbar-width and scrollbar-color properties, rather than this non-standard styling that I quoted above.

e.g. they could add this CSS rule, which is almost equivalent to the scrollbar styles that I quoted above, except without the explicit 6px and without the border-radius rounding:

.trending__items {
    scrollbar-color: var(--trending-scrollbar-color) var(--trending-scrollbar-background-color);
    scrollbar-width: thin;
}

They should be able to add the above rule (to get a reasonable look in all browsers that support those standard properties, which right now is just Firefox unfortunately) and then use the prefixed styles to specify the rounding and precise size in browsers that support those styles, I think (if they care to do so).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of how the site looks with suggested `scrollbar-color/scrollbar-width` styling added (Firefox on top, Chrome for reference on bottom)

(In reply to Daniel Holbert [:dholbert] from comment #5)

e.g. they could add this CSS rule, which is almost equivalent to the scrollbar styles that I quoted above, except without the explicit 6px and without the border-radius rounding:

Here's a screenshot showing Firefox on Windows 10 on top (viewed remotely within BrowserStack), with my suggested rule added; vs. Chrome 101 dev (on Linux) on bottom.

As you can see, the red scrollbar styling in the Trending area (from my suggested CSS rule) looks pretty similar to the styling that they get in Chrome with their prefixed styles.

Comment 7

[Daniel Holbert [:dholbert]]

Also: this isn't exactly a regression; it reproduces in old builds as well (e.g. in Firefox 70 on Windows 10 for me), depending on the conditions. If you're not seeing it, try making your window skinnier (to intentionally cause the component in question to get skinnier & for its contents to trigger a scrollbar).

The elements here are deceptively wide; they sort of look like they're just some text with space being evenly-distributed by the browser or something, but in fact each one is just text with 7px of padding and 15px of margin on each side, i.e. 44px of empty bonus-space per item (including 22px before the first one and 22px after the last one).

If the fonts/text/available-space/etc. work out just right so that the last item in this list happens to "mostly fit" except for its right-side margin and padding, then bug 1697349 will be the crucial difference as to whether a scrollbar appears or not. So, that's why (under certain conditions) this looks like a regression from that bug. But really, it was possible to trigger this before then, just under slightly-different circumstances (e.g. skinnier window, or wider snippets of text, or larger font-choice for the text in this list.)

So: one other thing that Toms Hardware might consider doing here would be to include a rule to take away that trailing margin and/or padding on the last item here. e.g.:

.trending__item:last-child {
  margin-right:0;
  padding-right:0;
}

This makes the unwanted horizontal-scrollbar disappear entirely for me (on Linux at least), when my browser window is maximized & the page has all the space that it wants to use here.

Comment 8

[Dianna Smith [:diannaS]]

:karlcow has anyone contacted Tom's hardware? or is the there another webcompat ticket for this?

Comment 9

[Karl Dubost💡 :karlcow]

And I can't reproduce on macOS whatever the settings of the OS (displayed all the time or only on interactions).
So at least that seems to be something related to Windows.

Ah wait you need to make the window narrow to make it visible. but even when I do that it doesn't create a major issue.
I think the scrolling area is expected. It is something I see on some sites where you can scroll a list of items. This is still the case in their mobile layout.

What is really missing in their CSS is a

/* Inline #2 | https://www.tomshardware.com/ */

.trending__items {
  scrollbar-width: none;
}

or thin as daniel mentioned in Comment #5

Tom's Hardware currently belongs to Future PLC
according to their job page, they seem to develop sites in-house.
https://apply.workable.com/futureplc/?lng=en

They are not on GitHub anymore.
https://github.com/FuturePublishing

but moved to GitLab.
https://gitlab.com/futureplc

https://gitlab.com/warmfusion
Toby Jackson seems to the most active.
https://uk.linkedin.com/in/toby-jackson-0b72a114
https://github.com/warmfusion

I sent a message through linkedin.

Comment 10

[Dennis Schubert [:denschub]]

We have a newer bug for this, bug 1886293, where we ship an intervention for this. I'll close this one as a duplicate of the newer bug, because the tracking flags are set up correctly there.