DocShell/Window targeting: Difference between revisions

m
GPHemsley moved page DocShell:Window targeting to DocShell/Window targeting without leaving a redirect
(Adding description of our current window targeting setup)
 
m (GPHemsley moved page DocShell:Window targeting to DocShell/Window targeting without leaving a redirect)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Current setup ==
= Current setup =
Window targeting is used for both <code>&lt;a target="name"&gt'</code>  and for <code>window.open(url, name)</code>.  The process works as follows:
Window targeting is used for both <code>&lt;a target="name"&gt;</code>  and for <code>window.open(url, name)</code>.  The process works as follows:


# Identify the docshell making the targeting request.  For links this is the container of the document the link is in.  For <code>window.open</code> calls this is the docshell of the window the script that calls <code>window.open</code> is running in.  This is the originating docshell.  In what follows we always make sure that the originating docshell is allowed to perform a load in any docshell that we find matching the name that was passed in.
# Identify the docshell making the targeting request.  For links this is the container of the document the link is in.  For <code>window.open</code> calls this is the docshell of the window the script that calls <code>window.open</code> is running in.  This is the originating docshell.  In what follows we always make sure that the originating docshell is allowed to perform a load in any docshell that we find matching the name that was passed in.
Line 11: Line 11:
# If no docshell with the given name was found, we examine the <code>"browser.link.open_newwindow"</code> pref to decide what to do.  As a result, we either redo the search using <code>"_top"</code> as the name, try top open a new tab using <code>nsIBrowserDOMWindow</code>, or open a new window using the window watcher.  This code is duplicated in docshell and in <code>nsGlobalWindow</code>.  In all cases, we end up returning a docshell (an existing one, or one from the new window or tab) to the caller.
# If no docshell with the given name was found, we examine the <code>"browser.link.open_newwindow"</code> pref to decide what to do.  As a result, we either redo the search using <code>"_top"</code> as the name, try top open a new tab using <code>nsIBrowserDOMWindow</code>, or open a new window using the window watcher.  This code is duplicated in docshell and in <code>nsGlobalWindow</code>.  In all cases, we end up returning a docshell (an existing one, or one from the new window or tab) to the caller.
# Once we have a target docshell, we proceed to do the load in it by calling either <code>LoadURI</code> (in the window watcher, for the <code>window.open</code> case) or <code>InternalLoad</code> (in docshell, for the targeted link case).
# Once we have a target docshell, we proceed to do the load in it by calling either <code>LoadURI</code> (in the window watcher, for the <code>window.open</code> case) or <code>InternalLoad</code> (in docshell, for the targeted link case).
= Proposed Changes =
I want to change step 8 to do the following instead:  If no docshell with the given name is found, get a "window provider" or something service and ask it for a new rendering area (nsIDOMWindow, probably, or nsIWebNavigation).  Pass in the initial target docshell (or its DOMWindow?) to this service, so that it can create new tabs, eg, in the right places (in the same window).  The service implementation would live in the embedding app (in toolkit or xpfe in Firefox/Seamonkey, for example) and would be free to return whatever window/webnavigation it wants.  If it returns nothing, we'd fall back to opening a new window via the window watcher as we do now.
In this setup, the webnavigation impl returned could do IPC or whatever it needs as necessary.  I don't see a reasonable way of doing POST across IPC short of defining our own IPC setup for it, so it would probably just throw on POST attempts.
We need to do something to fix steps 5 and 7.
== Comments ==
The use-case I'm running up against is a xulrunner-based "webrunner" (imagine gmail in a separate process). It will call window.open(url, "_blank") and I need to redirect this load into the externalprotocolhandler. I think I can hack this on the 1.8 branch by implementing nsIBrowserDOMWindow and setting "openinnewtab" to true, and then forcing nsIBrowserDOMWindow.openURI into the external protocol handler. The problem is that this catches all popup windows, whether they are meant to be "application popups" or "browser loads. I could imagine window.open("appwindow=true") to be overloaded so that webrunner apps could open app popup windows, or "external=true" to force open-in-default-browser. But both of those require coordinating windowwatcher with docshell.
--[[User:Benjamin Smedberg|bsmedberg]] 09:06, 28 Oct 2005 (PDT)
canmove, Confirmed users, Bureaucrats and Sysops emeriti
960

edits