[WebBrowser][Linking] WebBrowser with Linking listener not returning event data on Android on both Standalone & Expo Client

[WolfyUK]

🐛 Bug Report

Environment

  Expo CLI 3.0.10 environment info:
    System:
      OS: macOS 10.14.6
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 10.16.3 - /usr/local/bin/node
      Yarn: 1.17.3 - /usr/local/bin/yarn
      npm: 6.9.0 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    IDEs:
      Xcode: 10.0/10A255 - /usr/bin/xcodebuild
    npmGlobalPackages:
      expo-cli: 3.0.10

Targets: iOS, Android

Steps to Reproduce

1. Create new bare workflow app using expo-template-blank-typescript template
2. Implement WebBrowser with Linking listeners and a button to launch the browser

  launchBrowser = async () => {
    ...
    this.addLinkingListener();
    const result = await WebBrowser.openBrowserAsync(`${uri}/?returnUri=${Linking.makeUrl("return/path")}`);
    this.removeLinkingListener();
    ...
  }

  addLinkingListener = () => {
    Linking.addEventListener("url", this.handleRedirect);
  };

  removeLinkingListener = () => {
    Linking.removeEventListener("url", this.handleRedirect);
  };
  
  handleRedirect = (event) => {
    WebBrowser.dismissBrowser();
    const redirectData = Linking.parse(event.url);
    ...
  };

3. Allow page opened in browser to return to app via Linking.makeUrl() generated URI

Expected Behaviour

Listener should be called on Android device after deep link used to close the browser and return to the app with event data.

Actual Behaviour

Listener function is not called when running on Android device. This works fine on iOS.

Reproducible Demo

See this repo which contains a sample backend as well as Expo project.

The same behaviour is also observed in a bare workflow Expo project using custom deep links.

WebBrowser Redirect Example

The example against expo v32 as found here seems to work fine, and is basically the same as the repro above. I have forked this and changed to expo v34 here which also fails to return the expected data for Android.

[codGmer]

same here

[cruzach]

Is this happening in the Expo Client, a standalone app, or both?

[WolfyUK]

@cruzach I have only tested this in the Expo client

[WolfyUK]

I have just built and tested this in a standalone Android app and it is also failing.

[nlouischow]

same here

[mczernek]

As per documentation:

On Android promise resolves with {type: 'opened'} if we were able to open browser.

This means, that on Android promise resolves immediately after browser is opened. We are unable to determine moment when browser is closed, due to platform limitations.
It is inconsistent with iOS implementation, but we are fully aware of that and left it as it is, just in case someone needs that. Therefore, you cannot unregister your linking listener this way.

You might want to consider binding registration and unregistration of listener to some component lifecycle, or unregister it when handling lisntener's callback.

NOTE: dismissBrowser is also not available on Android! You should wrap its call in Platform.iOS calls.

[WolfyUK]

Hi @mczernek, thanks for looking into this issue. This does work in Expo v32 for Android. If support is no longer available please can you provide a more detailed workaround?

[mczernek]

It does, since we changed WebBrowser API in Expo 33. This change was enforced by migrating into much more powerful CustomTabs in WebBrowser module.
Workaround depends on specific use case. You need to be aware of the fact, that promise resolves on iOS immediately when browser is found and opened.

[WolfyUK]

@mczernek Please could you provide a workaround for the specific use case in the examples repo here?

Edit: It looks like this example was recently updated to v35. I'll see if this has made any difference.

[mczernek]

As mentioned in my first answer, you cannot invoke Linking.removeEventListener after openBrowserAsync promise resolves, as it resolves immediatelly after opening WebBrowser. This means that by the time browser tries to redirect to app, there will be no one to handle it.

You should either unregister it when handling listener's callback, or have some other condition for unregistering. Whichever fit's your case.

[WolfyUK]

The updated example still fails in Expo 35 so I'll see if I can fix it based on your feedback and submit a PR, unless this is something that you are able to assist directly with?

[mczernek]

PR is more than welcomed, I highly encourage you to submit one!

If for some reason you won't be able to make one, I'll do it :)

[mczernek]

@WolfyUK I've created an issue in examples repo. Feel free to refer to it in your PR.