When a new view is requested FrameLoader::createWindow() is called with the window features already set. Then, the window size it's adjusted for the difference between the window size and the page size. The page size is 0x0 because the new view is not yet realized, and the toplevel window containing the view is not shown yet, so the windowFrame we are reporting at this point is the default window size. So we end up adding the default window size to the size already set in the window features object.
Created attachment 119604 [details] Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment on attachment 119604 [details] Patch How does this impact the WindowProperties test, if at all? Would be good to update it. I had to disable asserting x and y because WebCore was handing us a wrong value for the y coordinate, this sounds like it could have a positive impact for that problem? =)
It doesn't affect the tests because in the tests the view is never realized beause we don't use a window, that's why I haven't noticed it until I impemented it in MiniBrowser, see bug #74711
btw, the unit test passes for me with and without the patch, so I don't know why Webcore reports a different x, y values, because coordintates are not adjusted in FrameLoader::createWindow() only the window size.
(In reply to comment #5) > btw, the unit test passes for me with and without the patch, so I don't know why Webcore reports a different x, y values, because coordintates are not adjusted in FrameLoader::createWindow() only the window size. Even if you add the asserts for x, y? Yeah, I digged quite a bit to try to find where the wrong value of y was coming from, but stopped when I reached WebCore, will have to dig a bit more from there.
Comment on attachment 119604 [details] Patch OK
Committed r103067: <http://trac.webkit.org/changeset/103067>