Open Bug 1284398 Opened 5 years ago Updated 6 months ago

[wfh] Firefox Android Nightly doesn't open Google Hangout links properly

Categories

(Firefox for Android :: General, defect, P5)

All
Android
defect

Tracking

()

Tracking Status
platform-rel --- +

People

(Reporter: amir.aharoni, Unassigned)

References

Details

(Keywords: webcompat:site-wait, Whiteboard: [sitewait] [country-all] [google][platform-rel-Google][platform-rel-GoogleHangouts])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506
Firefox for Android

Steps to reproduce:

I use Nightly as the default browser on my phone (Samsung Galaxy S7). I frequently use Google Hangouts, which I open as links from the Google Calendar app or by tapping on links. (My team at work uses a permanent Hangout URL.)

I'm testing this on Firefox Nightly 50.0a1 2016-07-04


Actual results:

When I click the Hangout URL, Nightly opens the Google Play store, which is useless. This started happening about a week or two ago.


Expected results:

In the past, the hangout would open in the Hangout app, which is the right thing to happen.

I changed the default apps on my phone, and now I have the Chrome app opening all URLs, and it opens the Hangout URLs correctly in the Hangout app. I'd love to put Nightly back as the default browser for URLs.
Component: Untriaged → General
Product: Firefox → Firefox for Android
OS: Unspecified → Android
Steps to reproduce:
A. Create new meeting on Calendar.google.com on the desktop (Google Calendar Android application doesn't seems to have this feature)
B. In the editing window, click on Hangout: Add video call.
C. Open the Android application, click on the Join Hangout link.

The link will open in browser, and will than redirect to Play Store.
Thanks, Tomer!
I see this behavior even on Firefox 47.
Tapping the hangout URL, will open a tab with Google Play store, saying that "Hangouts" app is already installed.
That was my worry. This sounded like a website behavior change. We won't be able to fix this bug. It would require the Hangouts or Calendar team to fix the redirect.
Status: UNCONFIRMED → NEW
Component: General → Mobile
Ever confirmed: true
Product: Firefox for Android → Tech Evangelism
Hardware: Unspecified → All
Version: 50 Branch → Firefox 47
Whiteboard: [needsdiagnostic] [country-all] [google]
There are steps I'm missing here to reproduce the bug. 

1. Open https://calendar.google.com/ on Desktop 
2. Click on Create (red button on the top left)
3. Create a fake meeting "testing hangout"
4. I can see "add video call", click on this.
5. Then Click on Save

On Mobile Firefox Android, open https://calendar.google.com/
Seeing the list of meetings, but that's all. No link for hangouts.


So I'm certainly missing something to reproduce and diagnose.
> On Mobile Firefox Android, open https://calendar.google.com/

This is the part that's wrong. You need to open the Google Calendar Android App -- for whatever reason the mobile version doesn't show the hangouts links (even on Chrome).

Once you click on "Join Hangout" the browser is opened then eventually you get the Google Play redirect.
GET "https://plus.google.com/hangouts/_/calendar/{snip}" => 302 w/ Location: "https://hangouts.google.com/hangouts/_/calendar/{snip}"

GET "https://hangouts.google.com/hangouts/_/calendar/{snip}" => 302 w/ Location: ""https://play.google.com/store/apps/details?id=com.google.android.talk&referrer=https://hangouts.google.com/hangouts/_/calendar/{snip}"

Karl, since this is apparently a recent change, can we ask Google if something changed? Testing in Chrome, it opens the Hangouts app successfully.
Flags: needinfo?(kdubost)
Mike, 

just to be sure. 

# Firefox browser by default:
---------------------------
Google Calendar Android App
  -> Join Hangout
  -> starts Firefox (automatically)
  -> Goes to Google Play


# Chrome browser by default:
---------------------------
Google Calendar Android App
  -> Join Hangout
  -> starts Chrome (automatically)
  -> Opens the Hangout app

I will contact Google.
Flags: needinfo?(kdubost)
Contacted today.
Whiteboard: [needsdiagnostic] [country-all] [google] → [sitewait] [country-all] [google]
After a big of back and forth with Google

> Android apps can indicate they handle specific 
> http(s):// URLs. The Hangouts app registers for 
> "http(s)://hangouts.google.com/hangouts/_/"... 
> Chrome must be checking for apps to handle URL 
> intents on the 302.

I wonder if someone on the Fennec team could check what should be done in Fennec to handle this kind of register. In the current setup it's not something which can be modified on the outreach side. 


Switching to Firefox for Android.
Component: Mobile → General
Product: Tech Evangelism → Firefox for Android
Version: Firefox 47 → unspecified
Mike has experience with intents from other apps.
Flags: needinfo?(michael.l.comella)
And for something which looks slightly similar: Bug 1143498
See Also: → 1143498
platform-rel: --- → ?
Whiteboard: [sitewait] [country-all] [google] → [sitewait] [country-all] [google][platform-rel-Google]
If I understand what's happening correctly, I think the flow between the Hangouts & Calendar app is not ideal based on Android convention – routing a url from an Android app into the browser to open an Android app seems strange.

Ideally: Calendar sends an intent specifically for Hangouts when the "Join Hangout" button is pressed, circumventing this URL load process.

Back-up plan: But perhaps they use http URLs so that they don't need to change what data is returned for a calendar event based on the client accessing them, which is fair. In this case, I'd expect the Hangouts app to register for the http Intent sent by the calendar app so it appears as an "open with app" choice when the link is pressed. For example, you see this when you click on YouTube or Maps URLs shared in other apps like text messages.

Back-up back-up plan: If we have to route through the browser, instead of using http urls on the pages only, the pages can provide intent URIs [1] to specifically try to open Android apps.

Karl, have the Hangouts or Calendars teams tried either of these approaches? Do they feel they're incorrect or is there a reason they can't do so?

[1]: https://developer.chrome.com/multidevice/android/intents
---

That being said, if this flow is not fixed like the above, Chrome works as users expect and Firefox does not so Firefox looks broken, meaning we may need to fix this anyway.

(In reply to Karl Dubost :karlcow from comment #10)
> After a big of back and forth with Google
> 
> > Android apps can indicate they handle specific 
> > http(s):// URLs. The Hangouts app registers for 
> > "http(s)://hangouts.google.com/hangouts/_/"... 
> > Chrome must be checking for apps to handle URL 
> > intents on the 302.

Given Mike's analysis:

(In reply to Mike Taylor [:miketaylr] from comment #7)
> GET "https://plus.google.com/hangouts/_/calendar/{snip}" => 302 w/ Location:
> "https://hangouts.google.com/hangouts/_/calendar/{snip}"
> 
> GET "https://hangouts.google.com/hangouts/_/calendar/{snip}" => 302 w/
> Location:
> ""https://play.google.com/store/apps/details?id=com.google.android.
> talk&referrer=https://hangouts.google.com/hangouts/_/calendar/{snip}"

That seems like what is happening. fwiw, I'm not sure this would be expected behavior and it could be that hangouts is taking advantage of the way things happen to work in Chrome, rather than the way they're documented to work (e.g. intent URIs would be a known solution here).

I've previously noticed different behavior in Chrome and Firefox where Chrome will open the Android app when you go to certain URLs (e.g. I think I've seen this with Youtube before) whereas Firefox will stay in the browser, but provide a page action to open the page in the associated app. Perhaps the difference in 302 behavior is why?

I'm also slightly concerned about the security of opening Android apps on redirection (though afaik web pages can arbitrarily open Android apps with intent URIs so perhaps I shouldn't be).

That being said, if we do need to try to open Android apps on 302, I'd expect the platform team to implement this because they better know about URL routing. In that case, I'd recommend pinging Snorp & he can handle off appropriately.

If you have more questions about Android Intent routing or need me again for any reason, please NI so I don't miss it!
Flags: needinfo?(michael.l.comella) → needinfo?(kdubost)
Thanks Michael. Very useful. 
I would say that we might need to fix it given that they didn't propose to fix it. 

Asking snorp :)
Flags: needinfo?(kdubost) → needinfo?(snorp)
Answer from Google

> So the change, was that the Hangouts app used 
> to also register for https://plus.google.com/hangouts/_ .. 
> and now only registers on https://hangouts.google.com/hangouts/_. 
> Which means we'd catch the correct app without the redirect.
>
> As to why we don't use intent://.. it's because the links 
> could come from anywhere (shared via chat/fb, or from 
> calendar). So to support those you register for https/http 
> URLs. In the best cases, the browsers are not even invoked, 
> since Android will simply launch the associated app.
(In reply to Karl Dubost :karlcow from comment #15)
> > So the change, was that the Hangouts app used 
> > to also register for https://plus.google.com/hangouts/_ .. 
> > and now only registers on https://hangouts.google.com/hangouts/_. 
> > Which means we'd catch the correct app without the redirect.

I'm not sure I fully understand – why was the `plus.google.com/hangouts/` address unregistered?

In any case, it sounds like this was an intentional change and, if we want the experience to work with Firefox as the default browser, we'll have to fix this on our end.

> > As to why we don't use intent://.. it's because the links 
> > could come from anywhere (shared via chat/fb, or from 
> > calendar). So to support those you register for https/http 
> > URLs. In the best cases, the browsers are not even invoked, 
> > since Android will simply launch the associated app.

Given this explanation, it makes sense to not use intent:// URIs if you register for all of the appropriate `http` URIs your app is expected to handle.
Flags: needinfo?(kdubost)
(In reply to Michael Comella (:mcomella) from comment #16)
> I'm not sure I fully understand – why was the `plus.google.com/hangouts/`
> address unregistered?

heh. This is out of my reach. Google internal decisions.

> In any case, it sounds like this was an intentional change and, if we want
> the experience to work with Firefox as the default browser, we'll have to
> fix this on our end.


Thanks.
Flags: needinfo?(kdubost)
platform-rel: ? → +
Whiteboard: [sitewait] [country-all] [google][platform-rel-Google] → [sitewait] [country-all] [google][platform-rel-Google][platform-rel-GoogleHangouts]
Rank: 50
Can we manually workaround this somehow? For example, is there a setting to specify a custom action for URLS starting with https://plus.google.com/hangouts/ ?

> So the change, was that the Hangouts app used 
> to also register for https://plus.google.com/hangouts/_ .. 
> and now only registers on https://hangouts.google.com/hangouts/_. 
> Which means we'd catch the correct app without the redirect.

So if this is an issue on the hangouts app side, does anyone know what would be the best way to bring it forward to them? This is actively hurting firefox usability (I had to run chrome browser on mobile for the first time to workaround this), and I've found tons of posts on google products forums, mostly ignored.
> So if this is an issue on the hangouts app side, does anyone know what would be the best way to bring it forward to them? This is actively hurting firefox usability (I had to run chrome browser on mobile for the first time to workaround this), and I've found tons of posts on google products forums, mostly ignored.

I don't think this is a bug in Hangouts, it's just a difference in how Chrome and Firefox process Android intents during handling redirects. It seems that Chrome will attempt to process the redirected URL with an intent at each step of the way, so when it receives the first redirect from plus.google to hangouts.google, it sends an intent which is handled by the Hangouts app. If the first intent didn't match Firefox, it proceeds to handle the whole redirect chain inside platform-independent HTTP code.

So, Firefox can mitigate in two ways:
 - one is easy and very ugly, namely somewhere in the code in Fennec which handles the intent coming in, like BrowserApp.java, do a pattern match for the plus.google.com link and instead invoke the intent for hangouts.google.com - which keeps the Android specific behaviour in the Android specific code, but encodes an assumption that Google's move from plus.google.com/hangouts to hangouts.google.com/hangouts is permanent
 - probably far harder to implement in Firefox and arguably not desirable, because it means after the platform intents have "decided" that Firefox should handle the link, we add something into the redirect chain handling which allows the Android-specific code to "handle" the interim URIs if they match with intents on the system.
I could not copy and paste the plus.google.com URL into Chrome to work around this issue.  Instead I had to set Chrome to the default browser following these instructions:

https://support.mozilla.org/en-US/kb/make-firefox-default-browser-android

Then opening the calendar link correctly redirected to the Hangouts app.
Just wanted to mention that this is still an issue, and that personally this keeps me from using Firefox on desktop as my primary browser. I need to be able to sync tabs and history, but not being able to connect to Hangouts on Android without switching my default browser is a deal-breaker.
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Summary: Firefox Android Nightly doesn't open Google Hangout links properly → [wfh] Firefox Android Nightly doesn't open Google Hangout links properly

This should work in Fenix now since they do see the redirected URLs.

You need to log in before you can comment on or make changes to this bug.