Comment 2 for bug 1300891

Ok, so I've had more of a thought about this API today - particularly wrt bug 1300884. The main issue with newViewRequested is that it's being used for what should be 2 separate tasks:

- Creating a new WebView
- Displaying the new WebView when it's ready.

It's currently called from 2 different code paths, with each path dispatching the signal at a different point (window.open() results in the signal being emitted when the renderer wants to show the newly created view. Clicking on a link results in it being called before anything is created in Chromium).

I think newViewRequested should be split in to 2 signals (newViewRequested and presentNewView, or something like that). The position property should be removed from NewViewRequest, and instead provided via the presentNewView signal. The way this would work is:

- On WebView.newViewRequested, the application creates a new WebView using the disposition as a hint for the type of view, but doesn't display it
- On WebView.presentNewView (or whatever it should be called), the application displays the new WebView (or not, if its a new background tab) using the provided position rect as a hint for the size and location of the new view if it's in a new window.

How does that sound? There is a precedent for this already - the WebKitGTK API splits this in to 2 signals as well