desktop oauth broken on Mac in Nightly

RESOLVED DUPLICATE of bug 1277028

Status

()

Core
Networking
RESOLVED DUPLICATE of bug 1277028
2 years ago
2 years ago

People

(Reporter: dietrich, Assigned: mayhemer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-next])

(Reporter)

Description

2 years ago
50.0a1 (2016-06-14)

The desktop oauth flow from Mac apps is broken on nightly when nightly is default browser.

Eg:

1. Install Vox music player app
2. Go to preferences and try to sign into your Soundcloud or Last.fm account
3. Nightly opens and after signing into the web page, I see this error about corrupted content:

https://i.imgur.com/VKpycQu.png

Works fine on release Firefox.

Comment 1

2 years ago
Maybe related to bug 1274729? Do you know when this broke? Patrick, do you know what might be wrong?
Component: General → Networking
Flags: needinfo?(mcmanus)
Flags: needinfo?(dietrich)
Keywords: regression, regressionwindow-wanted
Product: Firefox → Core
I think you need a real regression window here - I really hope bug 1274729 isn't the cause, the only change there was in the text when an error had already occurred. The error page and conditions that caused it were pre-existing, just some string changes.
Flags: needinfo?(mcmanus)
(Reporter)

Comment 3

2 years ago
Also broken in Dev Edition (48.0a2 (2016-05-29).
Flags: needinfo?(dietrich)
This might be fallout from prefetch (bug 1016628). If it is, there's a good chance it will be fixed when I land bug 1273882 and it gets merged to m-c. (And then fixed on aurora when bug 1278636 gets approved and landed there.)

Dietrich, can you try setting network.predictor.enable-prefetch to false and see if it works then?
Flags: needinfo?(dietrich)

Comment 5

2 years ago
 Dietrich did you tryed with e10s disabled? I try to test this issue on Mac OS X 10.10 with Nightly 50.0a1(2016-06-16) and with e10s enabled I manage to reproduce it but with e10s disabled my results were different. Please give it a try and see.
(Reporter)

Comment 6

2 years ago
(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #4)
>
> Dietrich, can you try setting network.predictor.enable-prefetch to false and
> see if it works then?

Did not make a difference.

(In reply to ovidiu boca[:Ovidiu] from comment #5)
>  Dietrich did you tryed with e10s disabled?

I tested, and yes this is an e10s bug.
Flags: needinfo?(dietrich)
Setting this as e10s ? and cc'ing the right people. Hopefully this hits e10s triage this week.
tracking-e10s: --- → ?
something with redirect went wrong, i think :)  ... looking at it.
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
The channel is redirected to:
com.coppertino.vox://lastfm/?token=.....

On e10s we end up at:
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpChannelChild.cpp#1559

If I type com.coppertino.vox://lastfm/?token=..... into address bar it will open it as it does on non-e10s.
We will need a universal channel (not Http, ftp channel) to implement nsIChildChannel, or something like that I am still not sure.
Whiteboard: [necko-next]

Comment 11

2 years ago
Dragan, how serious is this? Should it block e10s rollout?
Flags: needinfo?(dd.mozilla)
I'm guessing this means all non-standard protocols --> external helper apps are broken if they're the result of a redirect.  That's definitely not good :( I'm not the person to make the call about whether this blocks e10s or not, but I can certainly say that I wouldn't be shocked if it's a blocker.  I'm really not sure how often we use external helper apps (and how often links to them use redirects).  Jim, is there a designated person who makes the call on this?
Flags: needinfo?(jmathies)
I'm tentatively marking this as blocking on our general bug for supporting custom non-http/ftp protocols on e10s and assigning to Honza.  

Honza, this obviously has higher priority than things like supporting addons that use custom protocols (addons aren't supported for v1 of e10s, while this bug breaks intalls w/o addons).  So if there's a simpler fix that works just for this case, feel free to detach this from bug 590682.

Ideally we can do something simple and uplift.
Assignee: dd.mozilla → honzab.moz
Depends on: 590682
Flags: needinfo?(dd.mozilla) → needinfo?(honzab.moz)
(Assignee)

Comment 14

2 years ago
Sounds a bit like a redirect from http (or a protocol supporting redirects) to a custom or external protocol.  It more fits bug 1277028.

Dragana, can you confirm the above?
Flags: needinfo?(honzab.moz) → needinfo?(dd.mozilla)
(Assignee)

Comment 15

2 years ago
Dragana, thanks for analyzes and confirmation here! (made on IRC)

Clearly a dup.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jmathies)
Flags: needinfo?(dd.mozilla)
Resolution: --- → DUPLICATE
Duplicate of bug: 1277028
(Assignee)

Comment 16

2 years ago
Since I cannot verify this is fixed with the latest fix for bug 1277028 (v2) that only handles redirects to external protocols (not custom) I rather reopen this bug.  We may get it fixed with patch v1 from bug 1277028.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 17

2 years ago
(In reply to Honza Bambas (:mayhemer) from comment #16)
> We may get it fixed with patch v1 from bug 1277028.

Err... no longer :(  I was piggybacking on fact that ext protocol channel doesn't implement nsIChildChannel.  ext protocol channel is the channel we get in HttpChannelChild::SetupRedirect for an unknown protocol and v2 fix from bug 1277028 makes it impl nsIChildChannel.

Hence, now I really see only one way now - give add-ons tools to register their protocols on child (so that we use their implementation, that probably cannot be redirected to, tho - a show stopper) or let add-ons explicitly say "I want to be proxied" so that we use the generic channel from bug 590682 on demand.
(Assignee)

Comment 18

2 years ago
Dragana, does the Vox music player app install an add-on, or is it simply registering an external protocol handler in the OS?

Because if the letter, then this bug is a dup of 1277028.
(Assignee)

Comment 19

2 years ago
comment 18
Flags: needinfo?(dd.mozilla)
(Reporter)

Comment 20

2 years ago
Vox does not install an add-on. This is OS-level protocol registration. Like Spotify app support for Last.fm, and other integrations like that where a desktop app pops out to the browser for OAuth flow.
it does not install an addon. See comment 20 as well.
Flags: needinfo?(dd.mozilla)
(Assignee)

Comment 22

2 years ago
Thanks, then it is duplicate of bug 1277028.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
No longer depends on: 590682
Resolution: --- → DUPLICATE
Duplicate of bug: 1277028
tracking-e10s: ? → ---
Keywords: regression, regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.