I believe this may be related to this section of code in the commit that added support for repeating table headers?

    @@ -35,7 +35,43 @@
         return cell;
     }
     
    +void TableSectionPainter::paintRepeatingHeaderGroup(const PaintInfo& paintInfo, const LayoutPoint& paintOffset, const CollapsedBorderValue& currentBorderValue, ItemToPaint itemToPaint)
    +{
    +    if (m_layoutTableSection.getPaginationBreakability() == LayoutBox::AllowAnyBreaks)
    +        return;
    +    // TODO(rhogan): Should we paint a header repeatedly if it's self-painting?
    +    if (m_layoutTableSection.hasSelfPaintingLayer())
    +        return;

https://chromium.googlesource.com/chromium/src/+/81c0fc6d4e08e4e2bb4eb8a42747f21b13303616%5E%21/#F15

I am trying to get chromium building to play with this...

Hi @wh - if you're interested in picking this up that would be great. This is how I would fix it:

 - We need to do the same as PaintLayerPainter::repeatFixedPositionObjectInPages but for elements with their own layer inside a repeating header.
 - In order to figure out that the layer we're painting is inside a repeating header, I think we'll have to mark it during the paint invalidation phase (walking up the object tree to look for one would be far too expensive during paint). We would do this using PaintInvalidationState (see https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/paint/README.md) by setting a bit on PaintInvalidationState once we hit a repeating header while invalidating the tree. Setting this bit would allow us to mark (again with a new bit, see PaintLayer.h for bits used currently) any layers we subsequently hit as inside a repeating header.
 - Then when we're in PaintLayerPainter::paintLayerContents (i.e. doing the actual painting) we would check for this bit and if it's set (telling us that the layer is inside a repeating header) we would do the same thing repeatFixedPositionObjectInPages does today for fixed position objects.

Hopefully this helps! Let me know if you're confused by anything.

Some knowledge I'm probably unfairly taking for granted in the above:

 - Blink paints the DOM tree using a tree of items called layers.
 - Transformed elements, among other things like positioned objects, get their own layer.
 - The invalidate step I'm referring to starts in FrameView::invalidateTreeIfNeededRecursiveInternal(). This is where Blink walks through the entire DOM tree of the frame and marks each layer that it needs to paint at least a bit of. 'Invalidation' means 'mark an area on element for painting when you next do a paint of the frame'.

 Issue 777559  has been merged into this issue.

Running Version 71.0.3578.98 (Official Build) (64-bit),
looks like this is mostly working.

The test case I posted ends up with the "Rotated" text cut off at the top, but my production case works as expected.

Thanks Rob.