If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[e10s] Opening external links in e10s results in empty tab

VERIFIED FIXED in Firefox 35

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Julian Viereck, Assigned: mconley)

Tracking

({regression})

unspecified
Firefox 35
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(e10sm2+)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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.

Comment 1

3 years ago
Windows build is affected too (Nightly 35.0a1 (2014-09-15))
Blocks: 516752
OS: Mac OS X → All
Hardware: x86 → All
Linux as well.

Hitting Ctrl-L; Enter works to make Firefox load the page.
Quite a recent regression from bug 1047603.
Blocks: 1047603
Keywords: regression
Duplicate of this bug: 1067469
(Assignee)

Updated

3 years ago
Assignee: nobody → mconley
tracking-e10s: ? → m2+
(Assignee)

Comment 5

3 years ago
Bumping to the top of my priorities.
(Assignee)

Comment 6

3 years ago
Created attachment 8489814 [details] [diff] [review]
[e10s] Opening external links in e10s results in empty tab. r=?
(Assignee)

Comment 7

3 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).
Attachment #8489814 - Flags: feedback?(wmccloskey)
Attachment #8489814 - Flags: feedback?(dtownsend+bugmail)
Duplicate of this bug: 1067212
Duplicate of this bug: 1068576

Updated

3 years ago
Duplicate of this bug: 1068196
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
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Duplicate of this bug: 1068800
Duplicate of this bug: 1068866

Updated

3 years ago
Duplicate of this bug: 1068859
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 :-).
Attachment #8489814 - Flags: feedback?(wmccloskey)
Attachment #8489814 - Flags: feedback?(dtownsend+bugmail)
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1067595
Verified fixed on latest Nightly, build ID: 20150125030202.
The external links are now correctly displayed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.