When code in toolkit needs to open a web page it needs a way to respect Firefox's tabbed browsing settings. There is no appropriate component in toolkit for this bug so I chose Firefox -> Tabbed Browser. Bug 263433 is for supporting this from labels with class="text-link". Also see Bug 262575 and Bug 262808.

Since links in content documents already do the right thing, how easy would it be for links in chrome documents to do the right thing? Requiring <html:a target="_blank"> wouldn't be a too much of a problem because this would be incorporated into the text-link XBL, but I think it would be nicer still not to require it so that remote XUL could use text-link to replace the current page.

Neil, this is for providing a method from code and the text-link case is Bug 263433.

Well if untargetted chrome anchors can be made to work then so should this: window.QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIWebNavigation) .loadURI(href, Ci.nsIWebNavigation.LOAD_FLAGS_IS_LINK, null, null, null);

True, if a single solution for both cases is created it would be better.

> how easy would it be for links in chrome documents to do the right thing? What is "the right thing"? > When code in toolkit needs to open a web page it needs a way to respect > Firefox's tabbed browsing settings. What's the problem with just targeting it at _blank? Or using nsIBrowserDOMWindow?

(In reply to comment #5) >>how easy would it be for links in chrome documents to do the right thing? >What is "the right thing"? As suggested in the summary, it is whatever the default for the app is; in Firefox and SeaMonkey, this means as per tabbed browsing preferences, in other apps it means using the external protocol service. >>When code in toolkit needs to open a web page it needs a way to respect >>Firefox's tabbed browsing settings. >What's the problem with just targeting it at _blank? Or using >nsIBrowserDOMWindow? a) only Firefox and SeaMonkey can do that b) chrome _blank means _blank. [At least, it seems to ignore tabbed browsing prefs in my trunk build]

> As suggested in the summary, it is whatever the default for the app is; I've repeatedly said that I don't want to make behavior of lack of a target depend on whether "chrome" is involved or not. > a) only Firefox and SeaMonkey can do that They're also the only ones who implement the tabbed browsing prefs, so I don't see the problem. > b) chrome _blank means _blank. Not if you're using JS to call window.open on a content window, which is what I thought this bug was about. Yes, an <a target="_blank"> at the moment just opens a new window. Yes, we could change it. Yes, this would require that such things NEVER be used for opening other chrome windows (because we don't want to stuff the chrome in tabs). No, this is not the case last I checked. Is that about where we stand?

(In reply to comment #7) >>a) only Firefox and SeaMonkey can do that >They're also the only ones who implement the tabbed browsing prefs, so I don't >see the problem. The problem is that your solution is pointless in Thunderbird or XULrunner. >>b) chrome _blank means _blank. >Not if you're using JS to call window.open on a content window No content windows are involved with this bug.

> The problem is that your solution is pointless in Thunderbird or XULrunner. Again, neither one implements tabbed browsing preferences. How exactly do you expect them to do ANYTHING with tabs? > No content windows are involved with this bug. OK. So then we're back to a basic question: how do we tell whether chrome is opening a content thing or a chrome thing? I posit that the only way we can tell is if the chrome _tells_ us. Which means either a new api of some sort, or a new target that will only work in chrome or both.

(In reply to comment #9) >>The problem is that your solution is pointless in Thunderbird or XULrunner. >Again, neither one implements tabbed browsing preferences. How exactly do you >expect them to do ANYTHING with tabs? Sorry, the lack of (In reply to comment #0) confused me there. >how do we tell whether chrome is opening a content thing or a chrome thing? One possibility that comes to mind is the CHROME_OPENAS_CHROME flag, but that would mean having to parse the URL before deciding how to process window.open

> One possibility that comes to mind is the CHROME_OPENAS_CHROME flag Hmm... Yeah, if we could automagically set that somehow, that would be nice... Programmatically, with window.open(), that can already be done, right? Could we, for chrome windows, default that flag to on, and if it's explicitly disabled use the tabbed browsing prefs? Benjamin, what do you think of that? For <a target> things are harder, since you can't pass in options; again, perhaps a magic target value is the way to go. :(

(In reply to comment #11) >Programmatically, with window.open(), that can already be done, right? Could >we, for chrome windows, default that flag to on Most chrome is opened by window.openDialog(url, '', 'chrome ...' ...); anyway.

The pseudo-code I've used for this in a couple places is: if (externalprotocolhandler.isExposedProtocol("http")) uriloader.openURI(); // obeys tabbed-browsing prefs else externalprotocolhandler.loadURI(); I still think this behavior should be exposed to the DOM as: window.open("http://foo", "_blank", "external=yes"); or <a href="http://foo" target="_blank" rel="external">

(In reply to comment #9) >a new target that will only work in chrome or both. I suppose (target=)"_content" is no good, is it? (in content and browser chrome it would just load in the current tab).

> I suppose (target=)"_content" is no good, is it? You can use target="_main" and it'll work just fine, but we're talking about opening in a new browsing area (window or tab). Benjamin's proposal is pretty easy to get to work, esp. if we restrict it to chrome (as determined by the docshell type).

(In reply to comment #15) >>I suppose (target=)"_content" is no good, is it? >You can use target="_main" and it'll work just fine Isn't _main the IE-ism? Anyway, what I meant was what will or can it do when called from a chrome dialog in a) Firefox/Suite b) Thunderbird/Sunbird/etc.

In FF/Seamonkey _content and _main will find a random window and the current tab in that window. In the other apps, no idea.

Bug 384139 introduced openURL() to mozilla/toolkit/content/contentAreaUtils.js, which is what this bug asked for. The extension manager already uses it. It works for both browser and non-browser apps (Thunderbird), and respects the tabbed browsing settings of the browser. That's all this bug asked about.