1806339 - Grid: Incomplete fill or missing border depending on screen width

Status: NEW

(Core :: Layout: Grid, defect)

Description

[Vark]

Attachment: ffbug-expected.png

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

Steps to reproduce:

Display built using grid/flex components to represent a roster. Display under normal circumstances has every box with borders. Display should resize cleanly.

Actual results:

When adjusting the screen width (which should cause the boxes to resize) at certain widths (on my setup at 1986px wide) either a white space appears at the RHS of the box and before the border, or the border itself completely disappears particularly as you approach the lower limit set in CSS.

White space - ffbug-whitespace.png
No border - ffbug-noborder.png
Expected - ffbug-expected.png

Expected results:

The border should have remained visible, and no white space should appear, when resizing the display.

Comment 1

[Vark]

Attachment: ffbug-noborder.png

Comment 2

[Vark]

Attachment: ffbug-whitespace.png

Comment 3

[Vark]

This can be accessed at https://vark.nu/firefoxbug/

Note that it is just a passive demo of the bug, so you will see e.g. it will not load jQuery and some script elements will therefore not work.

Comment 4

[Vark]

Issue remains in 108.1 / Debian Bullseye

Comment 5

[Vark]

Issue not seen in current Chromium

Comment 6

[Monica Chiorean]

I am not able to reproduce the issue on Ubuntu 20.04 using Firefox build 107.0(20221110173214) and resizing the link https://vark.nu/firefoxbug/ works ok and scroll bar appears in the bottom of the page.
I will attach a screenshot from PC.
Also does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
And does this also happen with a new and empty profile? See https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile
Thank you.

Comment 7

[Monica Chiorean]

Attachment: Screenshot from 2022-12-22 12-44-09.png

Comment 8

[Vark]

Hi - thanks for your testing.

Your screenshot does display the most common issue. If you look at the orange coloured columns, in the second and third column there should be a black 1px line in the middle of each column, in the same way that the first and fourth column have them (there should be a border separating each day). The white 1px fail to fill only occurs for me at very specific screen widths. The datebar columns (at the top) do not show the border disappearing

It is still present in safe mode and with a new profile.

Also occurs on Windows FF 108.1 / Windows 10 in Normal and Safe mode and new profile.

There is a newer version of the CSS that does this layout at https://vark.nu/firefoxbug2, but I can still provoke the issue - at window widths under 1895px the missing border is always gone, and precisely at 1907, 1977, 2010, and 2047px wide the additional white vertical space appears. At 1897 to 1904px the border is visible. Generally as you increase the window width pixel by pixel the fault will appear over a few pixel variation then will paint properly.

Comment 9

[Monica Chiorean]

I'm still not able to see the issue on Win10x64 using FF 108.0.1(20221215175817).

Comment 10

[Vark]

I tested again in Windows 10x64 and Debain 10 / FF 108.0.1 on both

On Windows:
The orginal CSS still has the issue, easiest to see is the missing black vertical lines in the second and third orange coloured columns as you change the screen width. The appearance when needed of the scroll bar has never been an issue.
The new (firefoxbug2) CSS appears to have resolved the disappearing line issue (at least it wasn't triggered when I could trigger it in version 1), but not fixed on Debian (see below)

On Debian:
Both the original and version 2 of the code show the disappearing black line issue, and on Debian it's possible to trigger the whiteline issue at certain sizes as per above.

Added 3 new close in screenshots of orange column two at three different pixel widths (as the fault is width specific) using the second version of the CSS, to show the missing black line, the white line (2152px), and the correct display (2153px). Is there a better way I can show this fault in action? The missing black line is the most significant for me, because it disrupts the lines enough that end users will notice.

Comment 11

[Vark]

Attachment: Missing black line between orange column, 1895px

Comment 12

[Vark]

Attachment: White line, 2152px

Comment 13

[Vark]

Attachment: Correct, 2153px

Comment 14

[Vark]

Attachment: Missing border

After some more CSS changes I can't provoke the original bug (tho I do stil have a version that does), but I've found further evidence of something not calculating consistently with the screen width. This image shows the non-prod column (last in line) not having a right border, when it should (and the border appears when you change screen width), and if you look carefully at the lines with the cell containing "1" you can see that they are 1px longer than the orange bar above them - this should all be the same length. If you vary the browser width they will go from in line and correctly bordered to the situation in the screenshot.

Could this be a rounding or calculation error causing both scenarios?

Comment 15

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Flexbox' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 16

[Vark]

Attachment: right border borked

And now more of the rightmost border vanishes at various screen widths, presence of scroll bar doesn't matter, will try and get a static version of this CSS available on the test server.

Comment 17

[Vark]

FF updated to 108.0.2 on Debian, issue remains.

Comment 18

[Daniel Holbert [:dholbert]]

I wanted to take a look here, but the vark.nu site seems to be down at the moment (and https://downforeveryoneorjustme.com/vark.nu confirms it's not just me). I imagine this is a temporary issue, hopefully it's back up soon. (Firefox says "Hmm. We’re having trouble finding that site. We can’t connect to the server at vark.nu." and ping vark.nu says Temporary failure in name resolution.)

In the meantime: maybe you could post the testcase as an attachment on the bug here? That's always better, so that we've got a snapshot that's guaranteed to be available & static.

(If your testcase depends on external resources like external scripts or CSS: you could try doing "save-as: web page complete" or just copying the directory to a local folder -- and as long as the bug reproduces when you view that local testcase without requiring network access, then you could zip that up and post it as an attachment.)

Comment 19

[Vark]

Unfortunate timing, the provider for .nu domains had problems (one of their nameserver providers killed some servers) but these have now been resolved and the new nameservers should have propagated. I'll see however if I can get a static version of each of the tests I've built so far, and also of the latest. I will also see if I can minimize the test case for you.

(confirmed that vark.nu is back up as of now)

Comment 20

[Tiaan Louw [:tlouw]]

I was able to repro this on https://vark.nu/firefoxbug2/. It looks like a rounding issue. At very specific screen widths, the columns and grid lines are calculated to have a space in between or get collapsed (in the case where I could reproduce this).

At 2106x800 resolution I can see the very middle border line being collapsed, but of course at 2105 and 2107 the border is back again.

@dholbert do you want to add to this?

Comment 21

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from https://vark.nu/firefoxbug2/ , with jquery and font-styles removed)

Thanks. Here's a standalone (but not minimized) testcase as an attachment, just in case the nameservers have another bad day. :)

I can reproduce the missing-border bug here, in responsive design mode, with width=2065. (Responsive Design Mode is good for triggering this, since you can press uparrow/downarrow in that "width" field to exercise all of the individual whole-pixel viewport-widths and watch for borders disappearing.)

Comment 22

[Daniel Holbert [:dholbert]]

The border is actually there -- it's just covered up by the bisque-colored background of the preceding .weekend grid-cell. You can see that if you change that background to be a partially transparent color instead of bisque. E.g. if you replace background-color: bisque with background-color: rgba(255, 255, 255, 0.8); in the .weekend CSS rule, you'll see a very faint gray border (faint because it's now covered up by 0.8-opacity white from the overlapping previous cell).

There is a known CSS-Grid rounding bug when distributing space among cells -- this is likely an instance of that same bug, though I need to find the bug number.

(I'm updating the title to remove "flex" since that sounds like "display:flex", which doesn't actually come into play here and doesn't have the same rounding bug.)

Comment 23

[Daniel Holbert [:dholbert]]

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

There is a known CSS-Grid rounding bug when distributing space among cells -- this is likely an instance of that same bug, though I need to find the bug number.

That's bug 1201941.

Comment 24

[Vark]

I've cut some more of the un-needed code out of the tests provided. I now can't reproduce the odd far border vanish/1px out that I listed as the last example, but I've found another that might still be related given you've indicated its a background colour overwrite issue.

All the tests can now be found by going to https://vark.nu/ffbugs, with links now to 4 examples. 1 and 2 you've already seen.

3 and 4 relate to another border/background example, in the flags (these are the small coloured squares that appear under the "shifts"). In example 3 you will see that these have a lower 1px border irrespective of the background (transparent or coloured). In example four if you look at the flags when a background colour is set the lower border has gone/been overwritten. Exampe images to follow. I also found that when zooming (ctrl +) on the original fault you can see mis-draws of the flags where the background doesn't meet the border.

Comment 25

[Vark]

Attachment: Test 3 - flag fill appears to always work

Comment 26

[Vark]

Attachment: Test 4 - now the lower border is always overwritten/missing

Addit - this now never gives a white space, unlike the next one (test 1 showing white spaces on some zoom levels)

Comment 27

[Vark]

Attachment: Original test CSS, sometime the flag fills, sometimes a white space

This occurred when I zoomed twice into the display when I was trying to get better screenshots, but is reproducible. It comes and goes depending on zoom and appears to be similar in nature to the original spotted issue.

Comment 28

[Vark]

This continues to be an issue and disrupts the use of the layout (even in current versions of FF). Is there any workaround or fix for this?

Comment 29

[Vark]

Still present in FF 115.0.1 on Debian