PrepareFrameAndViewForPrint won't restore scroll offset if the main frame is remote |
||||
Issue descriptionThe following methods assume that the main frame is local (and will ignore scrolling offset): - PrepareFrameAndViewForPrint::ResizeForPrinting - PrepareFrameAndViewForPrint::RestoreSize The main frame will be remote in the following repro steps: 1. Launch chrome with --site-per-process 2. Navigate to https://csreis.github.io/tests/cross-site-iframe.html 3. Click "Go cross-site (complex page)" button 4. Inspect the subframe 5. Run window.print() in the subframe
,
Jun 19 2017
,
Jun 19 2017
I am a little bit surprised that when printing a single *subframe*, we resize the whole *page* at the end of PrepareFrameAndViewForPrint::ResizeForPrinting. If we didn't resize the whole page, then we wouldn't need to worry about restoring the scroll offsets for the page (and wouldn't have to worry about the case when the main frame is remote).
,
Aug 8 2017
weili: Do you want to take this one since it's OOPIF related?
,
Aug 9 2017
,
Feb 27 2018
When the main frame is remote, resize of WebView doesn't really change the viewport and scroll offset. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebViewImpl.cpp?type=cs&l=1761, so this should be fine. In a deeper look, I suspect with blink's new changes -- anchored scroll during resize, we no longer need to keep track of previous scroll. Will check more later, unblock main bug for now. |
||||
►
Sign in to add a comment |
||||
Comment 1 by lukasza@chromium.org
, Jun 19 2017