DocShell/Window targeting

Current setup

Window targeting is used for both <a target="name"> and for window.open(url, name). The process works as follows:

1. Identify the docshell making the targeting request. For links this is the container of the document the link is in. For window.open calls this is the docshell of the window the script that calls window.open 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.
2. Identify the docshell the targeting request is being made of. For links this is the container of the document the link is in. For window.open calls this is the docshell of the window whose open method is being called. This is the initial target docshell from now on.
3. FindItemWithName is called on the initial target docshell. From here on, we do each step only if the previous step found nothing.
4. The docshell checks for a few special target names that depend on the initial target: "_self", "_parent", "_top". If the name is one of those, the proper docshell is returned to the caller.
5. If the name is "_main" or "_content" the docshell's tree owner is asked for the relevant docshell. This part is rather buggy when tabs are involved in Firefox -- a load of "_main" or "_content" in any tab will target the currently selected tab.
6. The docshell tree that the initial target docshell is in is searched for a docshell with the given name, starting with the initial target docshell, then looking at its children, then searching the rest of the tree.
7. The initial target docshell's tree owner is asked to search for a docshell with the given name. This walks all open windows and searches for docshells with that name. Again, in Firefox this is buggy with tabs -- docshells that are not in the currently selected tab will not be found during this walk, since the enumeration we do only looks at "primary" content shells.
8. If no docshell with the given name was found, we examine the "browser.link.open_newwindow" pref to decide what to do. As a result, we either redo the search using "_top" as the name, try top open a new tab using nsIBrowserDOMWindow, or open a new window using the window watcher. This code is duplicated in docshell and in nsGlobalWindow. In all cases, we end up returning a docshell (an existing one, or one from the new window or tab) to the caller.
9. Once we have a target docshell, we proceed to do the load in it by calling either LoadURI (in the window watcher, for the window.open case) or InternalLoad (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.

We need to do something to fix steps 5 and 7.