Bug 183889

Sorry, I had forgotten to set a title.

I took a look into this. As I understand the logic of adjustScrollStepForFixedContent is to check if some fixed opaque content covers the full width at the top/bottom of the frame so that vertical page scroll can be adjusted appropriately on macOS. I guess we can re-use this logic but we have couple differences here. First since fixed content is relative to parent subframe, adjusting the page scroll of "overflow: auto" node does not seem to work in general (we would have to scroll the parent subframe to make the overflow node visible). Second, I'm not exactly sure page scroll makes sense on iOS and anyway here it's not page scroll but "scroll to reveal match" which ends up at scrollRectToVisible. Finally, in the AMP use case of bug 183658, the frame area is essentially the same as the "overflow: auto" area so we could apply the same logic but I wonder whether we should rather focus on making frame scrollable on iOS (bug 149264) in order to address these kinds of use case of "scrollable page with fixed-positioned header/footer".

Created attachment 336658 [details] Testcase (main frame) This is a testcase with the main frame. As I see: * For Ctrl+F: * On macOS, the text is revealed without scrolling the result away from the "position: fixed" overlay (so similar to iOS before bug 183658). * On iOS, the result is revealed at the center (so consistent with what is now done for overflow node after bug 183658) * For PageUp/PageDown: * On macOS, the header/footer are taken into account in adjustScrollStepForFixedContent to calculate the page step value. * On iOS, it's not clear to me. The scroll is initiated in the UI process while FrameView::adjustScrollStepForFixedContent (or even ScrollArea::scroll) is not called in the Web process.