Created attachment 8489154 [details] Screen Shot 2014-09-14 at 21.02.56.png This is tested on Nighlty 35.0a1 (2014-09-14) with opted-in e10s. Steps to reproduce: 1. I click on a link in an external app (e.g. a link in an email thread of Thunderbird) 2. Firefox gets the focus and a new tab is created 3. The URL in the Firefox URLBar is set to the clicked link Expected result: - The tab should load and the tab should show the title of the loaded page Actual result: - The tab is not loaded and the title is not set on the loaded page See also attached screenshot.
Windows build is affected too (Nightly 35.0a1 (2014-09-15))
Linux as well. Hitting Ctrl-L; Enter works to make Firefox load the page.
Bumping to the top of my priorities.
Created attachment 8489814 [details] [diff] [review] [e10s] Opening external links in e10s results in empty tab. r=?
Comment on attachment 8489814 [details] [diff] [review] [e10s] Opening external links in e10s results in empty tab. r=? Guh, tab opening stuff is kind of a mess. :( Here's what's going on: The nsContentTreeOwner caller of nsIBrowserDOMWindow::OpenURI expects and requires a return value of the actual nsIDOMWindow being opened, and that's what my patch in bug 1047603 fixes / provides. nsContentTreeOwner passes null as the URI, and then the resulting nsIDOMWindow is handed back which it then loads a URI in. nsBrowserContentHandler, which handles things like opening links from external processes, is a different story. That component calls nsIBrowserDOMWindow::OpenURI, and passes a URI to load in. It does not care about the nsIDOMWindow return value. It expects the URI to be loaded, and that's the end of it. Bug 1047603 breaks that second case because after we pass the URI to tabbrowser's loadOneTab, we start loading the page, and then a few lines after, we set the remoteness to false. This kills the browser / document loading. There are a few ways of fixing this - none of them are super pretty. I've just realized that this patch will not work in the event that the user's preferences result in aWhere in openURIInFrame being anything but Ci.nsIBrowserDOMWindow.OPEN_NEWTAB, so this patch is a non-starter. Alternatively, we could have openURI pass false for aEnsureNonRemote if a URI has been passed in... I'm not sure what's best at this point - this is all kind of dodgy. Open to suggestions (I'm also going to be low availability for the next few days, so if anyone else wants to pick this up while I'm gone, feel free - otherwise, I'll attack it between TRIBE sessions).
Backed out bug 1047603 at the request of ehsan and blassey. Hopefully we land test coverage for this when it re-lands. https://hg.mozilla.org/mozilla-central/rev/b50d767bb3e0
Comment on attachment 8489814 [details] [diff] [review] [e10s] Opening external links in e10s results in empty tab. r=? Sorry I never got to this. Your comment was very helpful for understanding bug 1047603 though :-).
Verified fixed on latest Nightly, build ID: 20150125030202. The external links are now correctly displayed.