Firefox rounds border-collapse table-row `getBoundingClientRect` in opposite direction from Chromium/WebKit
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
People
(Reporter: hgs, Unassigned)
Details
Attachments
(5 files)
screen shot shwoing offset by +1 fro top / left
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36
Steps to reproduce:
I want to overlay part of a table t1, with another table, overlay,by positioning the overlay table using the absolute position of top/left of the first row, in table t1. The given position of the first row form t1 is correct in Chrome, but off by +1 in Firefox (67.0.2 (64-Bit) on Win 10) for top/left, or Firefox is adding a border with of 1px for top and left border
The code below will show the effect.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
table {
border-collapse: collapse;
}
th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<table id="over" style="background-color:yellow;position:absolute;top:0px;left:0px">
<tr>
<td>xxxxxxx</td>
</tr>
<tr>
<td>yyyyyyy</td>
</tr>
</table>
<table id="t1">
<tr>
<th>head1</th>
<th>head</th>
<th>head</th>
</tr>
<tr>
<td>aaaaaaa</td>
<td>bbbbbbbbb</td>
<td>ccccccc</td>
</tr>
<tr>
<td>aaaaaaa</td>
<td>bbbbbbbbb</td>
<td>ccccccc</td>
</tr>
</table>
<script>
tab = document.getElementById('t1');
rect = tab.rows[1].getBoundingClientRect();
over = document.getElementById('over');
over.style.left = rect.left + 'px';
over.style.top = rect.top + 'px';
</script>
</body>
</html>
Actual results:
Element is not positioned correctly.
Expected results:
Element should be positioned on give top/left without offset as in Chrom, Opera and Brave
|
||
Comment 2•6 years ago
|
||
I managed to reproduce the issue on Nightly 69.0a1 (2019-06-18), Firefox 67.0.2 and 68.0b10, Windows, Ubuntu and Mac OS.
|
||
Comment 3•6 years ago
|
||
The priority flag is not set for this bug.
:mats, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•6 years ago
|
|
||
Comment 4•6 years ago
|
||
|
|
||
Updated•6 years ago
|
|
|
||
Comment 5•6 years ago
|
||
Here's a simplified testcase.
In Chrome this alerts (0,0).
In Firefox, it alerts (1,1).
|
|
||
Comment 6•6 years ago
|
||
This testcase, with a larger border, gets to the root of the problem. It's just a difference in rounding behavior, it looks like.
This testcase uses a border-width of 11px, and Chrome says the row's getBoundingClientRect is at (5,5) whereas Firefox says it's at (6,6). So this is just the border-width, divided by 2, rounded down (Chrome) or up (Firefox). Neither browser says that getBoundingClientRect is at the border top-edge, which is what this bug's reporter seems to have been expecting. (Though for a 1px-width border, Chrome's rounding-down behavior happens to produce that result.)
|
|
||
Comment 7•6 years ago
|
||
(In reply to hgs from comment #0)
Expected results:
Element should be positioned on give top/left without offset as in Chrom, Opera and Brave
Note that those aren't three independent results -- all three of those browsers use the same rendering engine (Chromium).
For comparison, Edge 18 (not using Chromium at this point) agrees with Firefox's visual rendering of testcase 1 here, and it reports more-exact fractional positions than either Chrome or Firefox do for testcases 2 and 3 -- it reports (0.5,0.5) and (5.5,5.5)
Safari 12.1 (WebKit) does agree with the Chrome results, though, for what it's worth.
Anyway -- I'll bet this is underspecified, like a lot of table rendering, and it's not too surprising that browsers do different things. I'll leave this open, though, because it's a legitimate compatibility issue even if we don't necessarily disagree with a spec.
|
|
||
Updated•6 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
Description
•