[Webkit-unassigned] [Bug 41441] createWindow method should only do window-creating without URL navigator

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41441





--- Comment #23 from Johnny Ding <jnd at chromium.org>  2010-11-16 01:20:35 PST ---
According to the previous discussion with Darin, we should find a solution, which can fix  all of the embedders to not load the request inside of createWindow. So we should be able to safely pass the target URL as the URL of the FrameLoadRequest.

According to my analysis, currently the createWindow are used in two scenarios:
1. called by window.open in JSBinding, this is the most common usage. In this scenario, before loading the URL, we have to set up the opener, openedByDOM, and dialogArguments values. Also, to decide whether to use the URL, we currently do an allowsAccessFrom call using the window we create, which can't be done before creating it, that is why WebKit passes empty URL to FrameRequest to avoid the URL navigation.

2. called by some places in where we just need to open a window to reload some resources, like a image or a webpage in a new window. It's triggered by user gesture. Currently it only was only used in ContextMenuController to respond users' actions in context menu.

In most time, currently the createWindow only do window-creating without URL navigator, just like its name. Even sometime it does the URL navigation, it can be broken into two parts: create window and navigate the specified URL.
However recently a new parameter NavigationAction was added to parameter list of createWindow (http://trac.webkit.org/changeset/70823), this parameter also can be used to indicate whether the createWindow will do URL navigation or not.

I personally think we have two options to fix this issue.
1. Explicitly Claim that the createWindow should only do window-creating without URL navigator. we remove all the URL navigation logic in all createWindow and related implementations. We pass the URL to FrameRequest parameter because some ChromeClientIMPL derived classes need the info (like do popup blocking). If caller wants to do navigation after creating window, just call newFrame->navigationScheduler()->scheduleLocationChange. 

2. Add a indicator in the NavigationAction parameter to indicate whether the createWindow allow a URL navigation, all createWindow and related implementations should check this indicator before doing URL navigation.

I prefer the option 1 because it makes the createWindow's logic more clear and we can eventually move it from the huge class: FrameLoader.

My co-worker, Xianzhu Wang(phnixwxz at gmail.com) has graciously volunteered to provide the patch for this issue since he is stepping in WebKit hack in recent months, so I step back to work onthe related chromium bug (http://crbug.com/38458).

Thanks.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.