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

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

With official Firefox build same problem.

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.

Paolo any ideas about this one?

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.

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.

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?

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

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

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?

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.

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

In think it is a dupe of bug 1394182.

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

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

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.