In order for "open in new window" menu selection to work in embedded apps, nsIWebNavigation needs a new LoadURI method that allows the caller to specify window targets. "_new" would be used to indicate a new window would be opened. This would take the burden of creating a new window by hand off of the embeddor/caller, and allow Gecko to properly target windows for content delivery.

I'm beginning to wonder if it wouldn't be better to just use the WindowWatcher service when a URI needs to be loaded into a new window... By using nsIWindowWatcher, we avoid changing the semantics of the nsIWebNavigation interface - which currently ALWAYS operates on a particular webBrowser instance... The only thing that we lose is the ability to specify load flags... Below is a code snippet that demonstrates how the Window Watcher could be used. // This code snipped assumes the following: // * webBrowser points to an instance of the nsIWebBrowser // interface... // // * uriString contains the string value of the URI to be // loaded... // nsresult rv; nsCOMPtr<nsIWindowWatcher> ww; nsCOMPtr<nsIDOMWindow> newWindow; nsCOMPtr<nsIDOMWindow> parentWindow; ww = do_GetService(NS_WINDOWWATCHER_CONTRACTID, &rv); if (NS_FAILED(rv)) return rv; rv = webBrowser->GetContentWindow(getter_AddRefs(parentWindow)); if (NS_FAILED(rv)) return rv; rv = ww->OpenWindow(parentWindow // DOM window parent uriString, // URL to load "_new", // Window name nsnull, // Window features nsnull, // Extra arguments getter_AddRefs(newWindow));

this sounds reasonable to me, could the load flags be added to the nsISupports argument list though?

Currently, the ISupports argument list is converted into a jsval array... So that OpenWindowJS(...) can be used. Currently, the WindowWatcher loads all URIs with LOAD_NORMAL attributes... I guess the real issue is whether we would ever need different attributes. I guess that if different attributes were required, the WindowWatcher could still be used to get/create the new window. However, if no URIString were passed in, the nsIDOMWindow that was returned could be used to get the corrosponding nsIWebNavigation interface - where the load attributes could be specified. Since there is an alternative way, I'm leaning toward futuring (or invalidating) this bug for now... What do people think? -- rick

I'm resolving this as invalid after talking with jud :-) Since there is an existing way to do this - lets not worry about it! -- rick

verifying.