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](https://bug1434366.bmoattachments.org/attachment.cgi?id=8946778), 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). (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%, 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.
Bug 1434366 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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](https://bug1434366.bmoattachments.org/attachment.cgi?id=8946778), 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%, 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.
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](https://bug1434366.bmoattachments.org/attachment.cgi?id=8946778), 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%, 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.
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](https://bug1434366.bmoattachments.org/attachment.cgi?id=8946778), 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.