STR:

1. Open the attachment.
2. Scroll down the container.
3. Observe that the scrolltop always increases but getBoundingClientRect().top always returns a constant value at one point.

This does work in Chrome.
Note: we use this in the profiler for our virtual lists (but will probably move to scrollTop because of this issue), and we found this when looking at the marker table in this profile.

Missing attachment?

🤦

(In reply to Julien Wajsberg [:julienw] from comment #0)

STR:

1. Open the attachment.
2. Scroll down the container.
3. Observe that the scrolltop always increases but getBoundingClientRect().top always returns a constant value at one point.

This does work in Chrome.
Note: we use this in the profiler for our virtual lists (but will probably move to scrollTop because of this issue), and we found this when looking at the marker table in this profile.

At 2., you'll need to scroll using the scrollbar, because you need to scroll below approximately half the height.

Call tree down to:

#0  nsLayoutUtils::TransformFrameRectToAncestor (aFrame=0x7f6df13af380, aRect=..., aAncestor=..., aPreservesAxisAlignedRectangles=0x0, aMatrixCache=0x0, aStopAtStackingContextAndDisplayPortAndOOFFrame=false, aOutAncestor=0x0)
    at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:2541
#1  0x00007f6e03b59638 in nsLayoutUtils::TransformFrameRectToAncestor (aFrame=0x7f6df13af380, aRect=..., aAncestor=0x7f6df13ae020, aPreservesAxisAlignedRectangles=0x0, aMatrixCache=0x0, aStopAtStackingContextAndDisplayPortAndOOFFrame=false, aOutAncestor=0x0)
    at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.h:890
#2  0x00007f6e08f1c387 in BoxToRect::AddBox (this=0x7ffeb249eae0, aFrame=0x7f6df13af380) at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:3671
#3  0x00007f6e08ed8189 in nsLayoutUtils::AddBoxesForFrame (aFrame=0x7f6df13af380, aCallback=0x7ffeb249eae0) at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:3569
#4  0x00007f6e08ed81e0 in nsLayoutUtils::GetAllInFlowBoxes (aFrame=0x7f6df13af380, aCallback=0x7ffeb249eae0) at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:3577
#5  0x00007f6e08ed853b in nsLayoutUtils::GetAllInFlowRects (aFrame=0x7f6df13af380, aRelativeTo=0x7f6df13ae020, aCallback=0x7ffeb249eb58, aFlags=1) at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:3734
#6  0x00007f6e08ed884f in nsLayoutUtils::GetAllInFlowRectsUnion (aFrame=0x7f6df13af380, aRelativeTo=0x7f6df13ae020, aFlags=1) at /home/dshin/mozilla-unified/layout/base/nsLayoutUtils.cpp:3774
#7  0x00007f6e09072fdd in nsIFrame::GetBoundingClientRect (this=0x7f6df13af380) at /home/dshin/mozilla-unified/layout/generic/nsIFrame.cpp:7757

Then the value gets clamped here.

The clamping is overaly pessimistic because the returned Rect is still
float-based, and the call site does its own clamping to nscoord.
Clamping to float's numeric limit causes significant floating point errors
when clipping the transformed rect, resulting in incorrect transforms.

https://hg.mozilla.org/mozilla-central/rev/1673f98a5005

Reproducible on a 2023-05-15 Nightly build on Windows 10 using the attachment from Comment 2.
Verified as fixed on Firefox 115.0b5(build ID: 20230613195413) and Nightly 116.0a1(build ID: 20230615094111) on Windows 10, macOS 12, Ubuntu 22.

bug 1839550 demonstrates that we effectively regressed on bug 1419225.
Re-opening for further work once the backout in bug 1839550 goes through.

I believe this was backed out of Firefox 115 and 116 in bug 1839550