1434366 - left border missing in calendar at feuerwehr-eisolzried.de

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[midzer]

Attachment: Screenshot-2018-1-30 Willkommen.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce:

Navigate to https://feuerwehr-eisolzried.de/ and check left Border of JavaScript generated calendar under "Termine"

Posted under https://github.com/webcompat/web-bugs/issues/15155 as well.


Actual results:

Calendars left 1px border is not shown


Expected results:

Left 1px border should be shown (same as Chromium)

Comment 1

[Alice0775 White]

Attachment: testcase

it is reproducible in case of the following combination.
container overflow-x is auto,
thead th without border,
tbody td with border.


div.container{
    overflow-x: auto;
}
table {
    border-collapse: collapse;
}
td {
	border:1px solid #aeaeae;
	width:5em;
	height:5em;
}

  <div class="container">
    <table>
      <thead>
        <tr>
          <th></th>
          <th></th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td></td>
          <td></td>
        </tr>
      </tbody>
    </table>
  </div>

Comment 2

[Mike Taylor [:miketaylr]]

Seems related to border-collapse on the table as well as the following rule on its parent:

.table-responsive {
    display: block;
    width: 100%;
    overflow-x: auto;
    -webkit-overflow-scrolling: touch;
    -ms-overflow-style: -ms-autohiding-scrollbar;
}

Removing the overflow-x declaration makes the left border re-appear.

Possibly related (or dupes): 

https://bugzilla.mozilla.org/show_bug.cgi?id=224613
http://forums.mozillazine.org/viewtopic.php?f=25&t=471493

Comment 3

[Mike Taylor [:miketaylr]]

(ah, thanks Alice :))

Comment 4

[Karl Dubost💡 :karlcow]

Attachment: test-case with outlines

So i we put a green outline on the div container of the test case
and a red outline on the first td of the table.

We can see the left cutout for the first td

Comment 5

[Karl Dubost💡 :karlcow]

Another funny one which renders differently in Chrome. Bug 242998
It seems overflow and tables are not good friends.
https://bugzilla.mozilla.org/buglist.cgi?list_id=13990817&short_desc=overflow&resolution=---&query_format=advanced&short_desc_type=allwordssubstr&component=Layout%3A%20Tables&product=Core

Comment 6

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 7

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's another testcase -- overflow isn't actually needed here, it just is one way of demonstrating the problem, which is that we draw the table's borders too far towards the "start" edge (which makes them overflow off of the start side of the table's containing block in this situation).

Comment 9

[Daniel Holbert [:dholbert]]

dshin, you've been looking at border-collapse edge case bugs recently -- perhaps you could take a look here when you've got cycles for a one-off webcompat bug?

Comment 10

[Daniel Holbert [:dholbert]]

(This bug seems to happen specifically when there are empty rows, just like bug 1819266 did, FWIW. If I remove the empty first row from my just-attached testcase, then the issue goes away.)

Comment 11

[David Shin[:dshin]]

Hm, WebKit does the same thing as us. Blink doesn't write over the .container's border in inline-start, but does in block-start direction.
All 3 engines fit the entire border-collapsed table in the .container if the empty row is removed.

Root cause is that we only depend on the first row to set the table's inline-start/end border width. Since there's nothing contributing to the border in the empty row (Since only the cells have borders), we set the inline-start border to be 0px. block-start behaves similarly; however, given that an empty row can still have a height (But not width) as a display: table-row box, this current behaviour for block-start border seems more correct (Feels unexpected, still).

Comment 12

[David Shin[:dshin]]

Attachment: A bit more generalized case

Generalizing the problem a bit:
This behaves differently on Gecko/WebKit vs Blink.
For Gecko/WebKit, black border wraps to the first row's red border.
For Blink, black border wraps to the largest red border, which is from the last cell.

CSS table spec seems to indicate that Blink's behaviour is more correct:

[...] set the table-root border-{…}-width to half the maximum width found during the harmonization processes for that border [...].

Comment 13

[Daniel Holbert [:dholbert]]

Complicating things slightly: our behavior isn't quite the same as WebKit's here, and (good news!) we did improve on this bug a bit recently.

Details:
(1) the original testcase here, WebKit never fully clips the left border at any full-page-zoom-level (though they do render it thinner than the other borders at certain zoom levels).

Whereas: until recently (per below), Firefox did fully clipp the left border, for all zoom levels < 200% (on a regular DPI monitor). And we do still fully-clip it at certain zoom levels.

(2) Good news, we've improved on that a bit, as of David's patch landing in bug 1825384! That patch improved things here substantially:

• The left border is now visible at zoom levels 100%, or 130%, 140%, 150%, 190% (and 200% which was already good)
• Though it's still clipped at zoom levels 110%, 120%, 125%, 133%, 170%

(Note: some of these zoom levels are only visitable using Ctrl-Mousewheel vs. Ctrl+; those two full-page zoom methods traverse different sets of intermediate zoom levels.)

Presumably in the cases where we still fully clip the border, it's just due to pixel-snapping artifacts, depending on the mapping of app units to display pixel values, and whether the border happens to pixel-snap fully off the start side of the element's clipping box. So maybe that remaining difference vs. WebKit isn't super meaningful; I haven't looked closely enough to be sure.

Comment 14

[Daniel Holbert [:dholbert]]

So in other words, the bug as-originaly-described is now fixed, at least at the default zoom level and 100% pixel-scaling settings

In Nightly from 1 month ago (2024-05-06), the bug still reproduces as-described at the url from comment 0, but there's no issue in current Nightly (with traditional 100% pixel-scaling settings, and no full-page-zoom). Though the left border does still disappear at certain zoom levels (the ones I called out as "still clipped" in comment 13).

So we might want to consider this bug FIXED by bug 1825384, and maybe spin off a followup for the remaining difference? (maybe reverting my bug-title-change from a month ago, since the current title seems to describe the remaining issue)

Comment 15

[Daniel Holbert [:dholbert]]

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

So we might want to consider this bug FIXED by bug 1825384, and maybe spin off a followup for the remaining difference?

--> doing that. I spun off bug 1901126 for the general "tables overflow off the start side" issue.

FWIW I verified that the testcase and the original website are fixed for me on Windows at 100% display resolution, though dshin found some configurations where the website is still broken for him at 100% display/zoom settings, which is odd.

I'll also file another followup for the fact that the original testcase/site here do still end up with the border getting clipped at certain zoom levels, in case we want to do anything about that (not sure, given that it will also be mitigated by bug 1901126, presumably).

Comment 16

[Daniel Holbert [:dholbert]]

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

I'll also file another followup for the fact that the original testcase/site here do still end up with the border getting clipped at certain zoom levels, in case we want to do anything about that (not sure, given that it will also be mitigated by bug 1901126, presumably).

Filed bug 1901133.

Comment 17

[David Shin[:dshin]]

Attachment: Testcase Where Left-Border Overlap Changes

The main content div is centered by having left and right margins set to auto, which can result in margins being set in the increment of 0.5px. This results in subpixel snapping shenanigans.
I can observe locally that on the website, changing the width of the viewport results in the left border flashing in and out of existence.
In the attached test case, changing the width of the viewport shimmies the table around, sometimes having it overlap with the left border.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to David Shin[:dshin] from comment #17)

In the attached test case, changing the width of the viewport shimmies the table around, sometimes having it overlap with the left border.

Ah, indeed! This is true for me at https://feuerwehr-eisolzried.de/ as well (in current Nightly), where the calendar's left-border disappears/reappears as I resize my viewport. (Whereas in older nightlies, before bug 1825384 was fixed, that border was just missing regardless of viewport size.)