Julian Viereck Reporter
	Description • 10 years ago

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.

	digi
	Comment 1 • 10 years ago

Windows build is affected too (Nightly 35.0a1 (2014-09-15))

	Chris AtLee [:catlee]
	Comment 2 • 10 years ago

Linux as well.

Hitting Ctrl-L; Enter works to make Firefox load the page.

	Tim Taubert [:ttaubert] (inactive)
	Comment 3 • 10 years ago

Quite a recent regression from bug 1047603.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 5 • 10 years ago

Bumping to the top of my priorities.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 7 • 10 years ago

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).

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 10 years ago

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

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 15 • 10 years ago

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 :-).

	Cornel Ionce [:noni] [Hubs QA]
	Comment 17 • 9 years ago

Verified fixed on latest Nightly, build ID: 20150125030202.
The external links are now correctly displayed.