Issue with Facebook links in Webview - ERR_UKNOWN_URL_SCHEME

[AnthonyFillionMaillet]

Preliminary Info

What Airship dependencies are you using?

18.1.4

Report

What unexpected behavior are you seeing?

Cannot open this landing page in app https://www.facebook.com/CarrefourPugetsurArgens/ through Arirship notification messages

Here is the console configuration link

Also facebook url was added in airship_url_allow_list array

But end up showing this error:

What is the expected behavior?

Opening this webview in app:

What are the steps to reproduce the unexpected behavior?

Send a message with https://www.facebook.com/CarrefourPugetsurArgens/ landing page value to your device with <item>https://*.facebook.com/*</item> in allow urls list

Do you have logging for the issue?

I suspect this issue come from redirection https://stackoverflow.com/questions/75148962/issue-with-facebook-links-in-android-webviewfragment-err-uknown-url-scheme

As you can see on my screenshot it tries to solve fb://profile/xxxxxxxx and fails When I open the link on mobile web browser like chrome I can see it goes through many redirection that could cause the issue

https://www.facebook.com/CarrefourPugetsurArgens/?utm_source=crf&utm_medium=part-g&utm_campaign=push_local -> Doesn't work ❌ https://www.facebook.com/CarrefourPugetsurArgens/ -> Doesn't work ❌ https://www.facebook.com/CarrefourPugetsurArgens -> Doesn't work ❌ https://www.facebook.com/ -> Works ✅

AirshipWebViewClient - fb://profile/100047632943714?wtsid=wt_1tUQpqYS9zYUhZwi6 is not an allowed URL. Airship Javascript interface will not be accessible.

[jyaganeh]

Hi @AnthonyFillionMaillet, and thanks for the detailed report.

I've been able to reproduce this in our sample app, and can confirm that intercepting and ignoring URLs with the fb:// scheme allows the page to load, but I think there are some issues that would remain with that workaround:

• The WebView that the landing page will be displayed in won't have access to any cookies that may exist in the user's actual browser app, so it will show the login modal until a user has logged into Facebook within your app. The login modal can be dismissed, and if the user logs in via the WebView, their authentication should be persisted within your app for future sessions.

• Several of the links on the FB profile page ('Open app', 'Message us', etc.) have links that point to intent:// URLs, which isn't something that we feel our SDK should handle automatically, since that involves interacting with other installed apps on the user's device and could leave an opening for unexpected or potentially malicious actions to be executed by an HTML InApp message.

• Because of the previous point, we'd need to expose a listener or handler in our API so that you can specify custom logic in your application to optionally intercept or handle URLs that would be loaded in WebViews (with the exception of uairship:// URLs, as those are handled internally by the SDK), so that you can take the appropriate actions for URLs that you expect to encounter. i.e., you could launch the facebook app directly for fb:// urls if the app is installed, or inspect intent:// urls to determine if your app should create and send an intent to the system to handle.

Ultimately, I think this comes down to Facebook doing some "interesting" things on their side, which don't quite match what we normally expect from HTML InApp content. It won't be particularly difficult for us to add a way to set a WebView URL handler as part of the SDK's config, but I'd like to make sure that would suit your use case, and that you're ok with the potential trade-offs of certain URLs needing to be handled via your implementation.

The primary concern I'd have with that approach is that we have no guarantees that Facebook won't add or change fb:// or intent:// links, so there may be continuing effort required on your part to ensure that links on FB profile pages are properly handled.

[AnthonyFillionMaillet]

Hi @jyaganeh,

Thank you for the detailed report. I agree with your assessment that while intercepting and handling the URLs as you suggested could work, it will require ongoing effort from both sides without any guaranteed long-term solution.

It’s clear that Facebook’s approach to handling these URLs is not standard, and there’s always a risk that they could modify or add new fb:// or intent:// links, which would necessitate further updates to our implementation. This introduces uncertainty and a potential maintenance burden moving forward.

Moreover, it’s worth mentioning that our reliance on Facebook links is quite limited, so while this workaround might address the issue for now, it may not be the most sustainable approach in the long run.

I’ll go ahead and close the issue. Thanks for your help.