Bug 74709 - [GTK] Window frame should be 0x0 when the toplevel window is not visible
Summary: [GTK] Window frame should be 0x0 when the toplevel window is not visible
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 74711
  Show dependency treegraph
 
Reported: 2011-12-16 05:29 PST by Carlos Garcia Campos
Modified: 2011-12-16 06:42 PST (History)
3 users (show)

See Also:


Attachments
Patch (1.43 KB, patch)
2011-12-16 05:32 PST, Carlos Garcia Campos
gustavo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2011-12-16 05:29:29 PST
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.
Comment 1 Carlos Garcia Campos 2011-12-16 05:32:32 PST
Created attachment 119604 [details]
Patch
Comment 2 WebKit Review Bot 2011-12-16 05:37:38 PST
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 3 Gustavo Noronha (kov) 2011-12-16 05:57:04 PST
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? =)
Comment 4 Carlos Garcia Campos 2011-12-16 05:59:55 PST
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
Comment 5 Carlos Garcia Campos 2011-12-16 06:02:14 PST
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.
Comment 6 Gustavo Noronha (kov) 2011-12-16 06:09:12 PST
(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 7 Gustavo Noronha (kov) 2011-12-16 06:10:27 PST
Comment on attachment 119604 [details]
Patch

OK
Comment 8 Carlos Garcia Campos 2011-12-16 06:42:02 PST
Committed r103067: <http://trac.webkit.org/changeset/103067>