Confirmed. Not sure why it's only happening on Android, however. In device emulation it shows up super obviously. Are we painting the td background rect assuming there's a border?

This may be fixed by crbug.com/485650. Assigning to myself to confirm.

crbug.com/485650 does not fix this issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Will take a quick look. Seems related to page scale (not device scale).

I debugged with the attached minimized test case using devtools mobile emulation. Based on paint verbose logging, paint results seem all correct:

            {
              "method": "drawRect",
              "params": {
                "rect": {
                  "left": 8,
                  "top": 8,
                  "right": 972,
                  "bottom": 60
                },
                "paint": {
                  "textSize": 12,
                  "textScaleX": 1,
                  "textSkewX": 0,
                  "color": "#FFFF0000",
                  "strokeWidth": 0,
                  "strokeMiter": 4,
                  "flags": "AntiAlias",
                  "filterLevel": "Low",
                  "textAlign": "Left",
                  "strokeCap": "Butt",
                  "strokeJoin": "Miter",
                  "styleName": "Fill",
                  "textEncoding": "UTF-8",
                  "hinting": "Normal"
                }
              }
            },
            {
              "method": "drawRect",
              "params": {
                "rect": {
                  "left": 8,
                  "top": 8,
                  "right": 972,
                  "bottom": 60
                },
                "paint": {
                  "textSize": 12,
                  "textScaleX": 1,
                  "textSkewX": 0,
                  "color": "#FF808080",
                  "strokeWidth": 0,
                  "strokeMiter": 4,
                  "flags": "AntiAlias",
                  "filterLevel": "Low",
                  "textAlign": "Left",
                  "strokeCap": "Butt",
                  "strokeJoin": "Miter",
                  "styleName": "Fill",
                  "textEncoding": "UTF-8",
                  "hinting": "Normal"
                }
              }
            }

And the visual rects are also correct.

The effect seems a result of rasterization of anti-aliased sub-physical-pixels along the edge of the rectangles, when page-scale-factor * device-scale-factor is not integral. Is this another failure of bleed avoidance?

This sounds a lot like https://bugs.chromium.org/p/chromium/issues/detail?id=431480#c5.  At least in the past, tables haven't handled subpixel positioning for spec reasons.

This bug seems different from  bug 431480  and not related to subpixel table layout because
- all the painting commands shown in #c8 are using integral geometries;
- the bug doesn't occur when adjusting zoom factor;
- the bug occurs on mobile devices and mobile emulation (which have page scale when displaying desktop pages).

Based on observation with mobile emulation, I think the hair line occurs because when we raster the td background, the geometries are not integral and the edge pixels are blended with the pixels of the table background, showing with a red hue.