This is the Windows version of bug 53814.
Unlike the Mac, on Windows we just need to be able to set the scroll offset to be applied the next time the view is sized, since we change the size separately.
Created attachment 85733 [details] Patch
Comment on attachment 85733 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=85733&action=review The "on next size" terminology is a little confusing. "on next resize" would be slightly clearer. Is there any downside to making the Windows API match the Mac API? > Source/WebKit2/UIProcess/win/WebView.cpp:503 > if (m_page && m_page->drawingArea()) > - m_page->drawingArea()->setSize(IntSize(width, height), IntSize()); > + m_page->drawingArea()->setSize(IntSize(width, height), m_nextSizeScrollOffset); > + > + m_nextSizeScrollOffset = IntSize(); Should we only clear out m_nextSizeScrollOffset when we actually call setSize? > Source/WebKit2/UIProcess/win/WebView.cpp:805 > + ASSERT(m_nextSizeScrollOffset.isZero()); I don't think we can assert this. A WebKit client app could call this API twice in a row without allowing any messages to be processed.
(In reply to comment #3) > (From update of attachment 85733 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=85733&action=review > > The "on next size" terminology is a little confusing. "on next resize" would be slightly clearer. Is there any downside to making the Windows API match the Mac API? I'll change it to use on next resize. I didn't attempt to match the Mac API since the resizing is done inside Safari. > > > Source/WebKit2/UIProcess/win/WebView.cpp:503 > > if (m_page && m_page->drawingArea()) > > - m_page->drawingArea()->setSize(IntSize(width, height), IntSize()); > > + m_page->drawingArea()->setSize(IntSize(width, height), m_nextSizeScrollOffset); > > + > > + m_nextSizeScrollOffset = IntSize(); > > Should we only clear out m_nextSizeScrollOffset when we actually call setSize? Sounds good. > > > Source/WebKit2/UIProcess/win/WebView.cpp:805 > > + ASSERT(m_nextSizeScrollOffset.isZero()); > > I don't think we can assert this. A WebKit client app could call this API twice in a row without allowing any messages to be processed. I will remove the assert.
Created attachment 85743 [details] Patch
Committed r81082: <http://trac.webkit.org/changeset/81082>