Right now, Metro Firefox defaults to opening new tabs whenever you type a URL into the URL bar or whenever you click on links. Pages will only open in the current tab if and only if the page uses the HTML5 History API to modify the URL. This is controlled by this line: https://mxr.mozilla.org/projects-central/source/elm/browser/metro/base/content/browser.js#501

Turns out that this bug is actually related to going single-process. To ensure that all links clicked on chrome pages (e.g. about:home) open in new tabs, there's an extra handler for DOMActivated that makes all http/https links open in new tabs. Chrome pages are detected by determining if the current page is in the parent process. Because we're single-process, *every* page is in the parent process, causing link opening (and a few other functions, like drag events) to fail. I'm going to switch chrome page detection over to a less robust system similar to what prior revisions of content.js in fennec-xul did: check if top.location has a local URI scheme (about:).

Put together a quick test case since I couldn't think of any web pages off the top of my head that used target="_blank" to load new tabs.

Issue that's still a problem: the DOMActivate listener will cause new tabs to open when you type in a URL when you have a chrome page in your selected tab. Opening new tabs when links are clicked from chrome pages as the default through content.js seems hacky. The chrome pages themselves ought to use link targets (and/or message passing) properly to open new tabs if needed, given that they're privileged. I can assemble a patch to remove this for once, so we don't have to trip over this in the future. Thoughts?

(In reply to Jonathan Wilde [:jwilde] from comment #5) > Issue that's still a problem: the DOMActivate listener will cause new tabs > to open when you type in a URL when you have a chrome page in your selected > tab. > > Opening new tabs when links are clicked from chrome pages as the default > through content.js seems hacky. The chrome pages themselves ought to use > link targets (and/or message passing) properly to open new tabs if needed, > given that they're privileged. > > I can assemble a patch to remove this for once, so we don't have to trip > over this in the future. Thoughts? I think this is good. If and when we go back to oopc, issues that forced us to do these new tab from chrome hacks should be addressed properly. For example you should be able to open a remote tab in a chrome tab.

Landed http://hg.mozilla.org/projects/elm/rev/1bf3b1479de7

Missed a point where this was being implemented. New tabs should no longer be arbitrarily be generated. http://hg.mozilla.org/projects/elm/rev/dd719b5576ee

Resolving bugs in the Firefox for Metro product that are fixed on the elm branch. Sorry for the bugspam. Search your email for "bugspam-elm" if you want to find and delete all of these messages at once.