This new failure in test_scroll_space_no_range_overflow_scroll.html is fun. The test calls pageMove. PresShell::PageMove calls GetNearestScrollableFrameForDirection. The root scroll frame of the test is scrollable (there is a 200 vh spacer in it), however when run within the mochitest testing harness iframe it is not scrollable (ie GetScrollStyles returns overflow hidden) because we set scrolling=no on it here
And the blame for that line appears to go back to 2007 when we first introducted mochitest. Long time viewers may remember bug 1199023, where I discovered that mochitest-chrome was using scrolling=no and removed it. I guess I didn't find this use of scrolling=no because it is applying the scrolling=no in a different way that a search wouldn't be able to easily find. If I remove that we fail maybe around 10ish tests:
Now, back to the problem at hand. So the root scroll frame of the test is determined to not be scrollable and so we traverse to the parent document, the one housing the mochitest harness. Before the patch of this bug we determine that there is no layout scrolling that can be done on the root scroll frame of the mochitest harness document and return null. After this patch we determine that there is apz scrolling that can be done and so return the root scroll frame of the mochitest harness document.
Then, without this patch, since we got a null frame we call nsFrameSelection::GetFrameToPageSelect to get the frame to use. With this patch we have a frame. Now we call nsFrameSelection::PageMove with the frame that we have. nsFrameSelection::PageMove calls GetOffsetTo between the passed in frame and the frame that the caret is in (the focused frame). Before this patch this is the root frame of the test document and a div in the test document. After this patch this is the root frame of the mochitest testing harness parent document, and a div in the test document. GetOffsetTo is not to be used on frames in different documents so this asserts, and then I think we try to scroll the test harness document, so the test doesn't see the scroll it is expecting.
So we need to remove scrolling=no from the mochitest iframe, but that looks to be a bit time consuming dealing with multiple tests and potential fallout. And we need to fix this code, as it is broken even with that problem. That seems a little more tractable in the short term to get this bug fixed. Initial question in my mind for that task is: if we don't find a scrollable scroll frame in the document of PresShell, should we ignore the PageMove call or forward the PageMove to a parent PresShell? Reading the description of the function in the idl it sounds like we should ignore it
because it is specifically dealing with the selection in one specific document. But it looks like there are two things going on: expanding the selection and scrolling. And while the selection may be limited within some subtree, the scrolling looks like it can maybe go above that: