1400803 - e10s break external protocol handler functionality

Status: RESOLVED DUPLICATE of bug 1382323

(Firefox :: File Handling, defect, P3)

Description

[RoMan]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170914154352

Steps to reproduce:

Ubuntu 16.04
Firefox 55.0.2

e10s cause any new external protocols to be unknown.

Steps to reproduce:
1) start Firefox with new profile, ensure e10s is enabled;
2) try to open any external link, for example apt://firefox;


Actual results:

redirect to Google search


Expected results:

link should be opened in external program, in our case in AptURL

disabling e10s solve this problem, all protocols which was opened first time without e10s will works as expected after enabling e10s

Comment 1

[Kohei Yoshino [:kohei]]

Please test with the official Firefox build instead of the Ubuntu build.

Comment 2

[RoMan]

With official Firefox build same problem.

Comment 3

[Kanchan Kumari QA]

I see same behavior with chrome. You are right, with non e10s it does ask to choose program to open the external link while with e10s it redirects to the default/selected search engine.

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

Paolo any ideas about this one?

Comment 5

[:Paolo Amadini]

Kanchan, testing only with e10s enabled, is this a regression or something that affects old versions of Firefox too?

Does the same issue happen in newer versions of Ubuntu? I tried on a recent version of Linux Mint and the issue doesn't happen.

Comment 6

[Kanchan Kumari QA]

This seems regression. I used mozregression found the following range:

Last good revision: 142098bba3d41b4a0ca6ef5bf58d6fcf5ad209fc
First bad revision: 142098bba3d41b4a0ca6ef5bf58d6fcf5ad209fc
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=142098bba3d41b4a0ca6ef5bf58d6fcf5ad209fc

I am using Ubuntu 16.04 x64.

Comment 7

[:Paolo Amadini]

Hi Kanchan, thanks for looking up the regression range, but I've taken a look and the only change I see doesn't seem relevant. Can you repeat and see if maybe there is anything intermittent affecting the bisection?

What about other versions of Ubuntu, are they affected by the bug?

Comment 8

[Kanchan Kumari QA]

(In reply to :Paolo Amadini from comment #7)
> Hi Kanchan, thanks for looking up the regression range, but I've taken a
> look and the only change I see doesn't seem relevant. Can you repeat and see
> if maybe there is anything intermittent affecting the bisection?

I got new regression range
12:47.96 INFO: Last good revision: a38df6f51b67ca3cd2de921dcfbb8cc8d5208973
12:47.96 INFO: First bad revision: a38df6f51b67ca3cd2de921dcfbb8cc8d5208973
12:47.96 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=a38df6f51b67ca3cd2de921dcfbb8cc8d5208973

> What about other versions of Ubuntu, are they affected by the bug?

I could reproduce this issue on Ubuntu 17.04 x64 too.

Comment 9

[:Paolo Amadini]

(In reply to Kanchan Kumari QA from comment #8)
> I got new regression range

Hm, this is from the next day and also doesn't look relevant, which makes me think that the issue may have existed for a long time and may be intermittent or difficult to track with mozregression.

> I could reproduce this issue on Ubuntu 17.04 x64 too.

Thanks, we should definitely look into fixing it at some point, though we don't know yet what has caused it in the first place.

Comment 10

[:Paolo Amadini]

Jan, you've probably looked at Linux protocol handling code more than me in these days. I wonder if you have an idea about this particular issue, or if you have encountered it before?

Comment 11

[Jan Horak [:jhorak]]

I can't reproduce with mozilla-central, but with Firefox 56, so I'll try to check what's the problem as soon as I have my debug build ready.

Comment 12

[Jan Horak [:jhorak]]

So far it seems to be because of some sandboxing of content process which calls nsGIOService::GetAppForURIScheme and subsequent calls of various GIO functions ends by access("/usr/bin/transmission-gtk", X_OK) returning -1 (as long as /usr/bin/transmission-gtk is executable, therefore should be returning 0).

Comment 13

[Jan Horak [:jhorak]]

In think it is a dupe of bug 1394182.

Comment 14

[Jan Horak [:jhorak]]

Setting security.sandbox.content.level to 1 is a workaround for this issue for me.

Comment 15

[RoMan]

(In reply to Jan Horak from comment #14)
> Setting security.sandbox.content.level to 1 is a workaround for this issue
> for me.

For me too.

Comment 16

[:Paolo Amadini]

Thanks, that's very helpful! Since it doesn't happen with Nightly, I strongly suspect this was fixed bug 1382323 in Firefox 58.

I'm duplicating this and bug 1394182 there, feel free to reopen if this is incorrect.