[Android] Share.open always return success: false & dissmissedAction: true

[donatoaguirre24]

Steps to reproduce

1. Use Share.open with android
2. Set failOnCancel: false

Expected behavior

The promise resolves if the user shares or dismisses, and the returned object contains success and dismissedAction properly set.

Actual behavior

The returned object always contains success: false and dismissedAction: true no matter if the user shared or dismissed the share sheet.

Environment

• React Native version: 0.64.2
• React Native platform + platform version: Android 11

react-native-share

Version: 6.4.0 (latest)

Repro

const handleShare = async () => {
  try {
    const { success } = await Share.open({ failOnCancel: false, title, url });
    // success always returns false and dissmissedAction always returns true (Android only)
    if (success) {
      Toast.show({ text1: strings.shareSuccess, type: 'info' });
    }
  } catch {
    Toast.show({ text1: strings.shareError, type: 'error' });
  }
};

I also tried without using failOnCancel: false but then the issue #784 happens :(

[kaioduarte]

I investigated this, but I'm not sure how to fix it.

This also happens with shareSingle when the forceDialog flag is true because we try to use the IntentSender from the TargetChosenReceiver class (code references for shareSingle and open).

However, the RESULT_CANCELED we check (code reference) is not accurate accordingly to the Android docs:

if the activity explicitly returned that, didn't return any result, or crashed during its operation.

I wonder if we can send 'success' at that point as the expo-sharing and the React Native packages do.

@mikehardy, any thoughts on this?

[mikehardy]

@kaioduarte looks like an incorrect assumption in the native android code here yes,

I'm not sure what you mean by RESULT_CANCELED not being accurate, as it appears accurate, I think you might mean "complete" - in that RESULT_CANCELED is accurate when it is the result code but it is only one integer and the result code could be any integer, with no other integers currently handled (so the current solution is incomplete)?

It does appear that to be complete, any result code that comes back as an activity result matching the request code should be handled. Ideally the interface would propagate the result code back up to javascript / API consumer then by maybe switching on result code and calling TargetChosenReceiver.sendCallback with a true then either an 'OK' (if that was the result code) or a default case of just passing the actual code on if it's > 1 (RESULT_FIRST_USER, which delimits > 1 as user-specific result domain) - those values will then be passed up to javascript where they may be used constructively?

react-native-share/src/index.tsx

Line 73 in 5ed224b

(success, message) => {

[kaioduarte]

@mikehardy, My point is that we can receive that code for more than one scenario (even for successful sharing).

I did some tests, and all of them returned the same code:

• successful sharing
• by canceling on the share sheet
• by opening the target app and leaving it without sharing.

It doesn't seem trivial to get the proper code. Otherwise, I guess Expo or RN would handle that.

[mikehardy]

Ah - there was an assumption in my comment that "accurate" was not the right word. But if you've done the real-world testing (instead of my blah blah blah theory / documentation reading) and it really is just coming back as RESULT_CANCELED all the time, including on successful share then it does seem intractable, and maybe just PR'ing a returns-every-time-but-is-documented-to-be-useless-with-regard-to-return-value change is the thing to do

[donatoaguirre24]

@kaioduarte @mikehardy is there anything we can do to help to fix this? Ready your comments I'm still not sure if this is an issue with the library or with the RN itself 🤔

[mikehardy]

If someone proposes a well-reasoned PR, it gets merged and released - that's the thing to do if there's an issue

[donatoaguirre24]

Yes, I know how OSS works. I'm not demanding a solution, I'm asking how I can help.

I want to understand the issue so I can do some research. I'm not an android developer so doubt I could submit the PR, but maybe I can test, debug, provide info, or open an issue in the RN repo if that's necessary.

Do you mind explaining what do you mean by: "PR'ing a returns-every-time-but-is-documented-to-be-useless-with-regard-to-return-value change is the thing to do" ?

"It doesn't seem trivial to get the proper code. Otherwise, I guess Expo or RN would handle that." Makes me think is an issue with RN itself

[mikehardy]

I believe the issue is actually the Android system not returning a useful value, and Expo and react-native (core) paper over the issue by just returning success all the time - we should do the same - just make a change where the actual return value that comes back in onActivityResult is ignored and you return success no matter what, and match it with a documentation change that explains the return value is useless because Android doesn't provide a valid return value, and that should do it

[ladas-larry]

Should this one be closed after merging #1078?

[donatoaguirre24]

Should this one be closed after merging #1078?

No, I tested it but the bug is still there 😔

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and i will leave this open

[mikehardy]

android share return value discussion should stay focused here, it has the most information. Open to PRs, but everyone understand - you need to read the comments ☝️ and after reading them the next step is a PR. Please post a PR if you're interested in a behavior change.

[iimry]

I'm revisiting this issue as my react-native app would like to be aware if an app was used or the Sharesheet was simply dismissed. As I was playing around with the code, I found that the onReceive method of the TargetChosenReceiver should be called when an app is selected (though this does not apply to the Copy function for whatever reason).

However, as the code stands, this method is never invoked and I found this is due to a couple lines of code that, when removed/changed, I think pretty much solves the issue here, at least for the .open function which is what I've tested.

1. Comment out Line 54 of TargetChosenReceiver
2. Change the call on Line 56 to only use the single flag PendingIntent.FLAG_UPDATE_CURRENT

By doing this, the JS will return an error (User did not share) when the Sharesheet is dismissed and when an app is clicked, it will return a success message of the clicked component string (com.google.android.apps.messaging/com.google.android.apps.messaging.ui.conversationlist.ShareIntentActivity).

However, before I submit a PR, I would like to know why these things currently exist and what happens if this were to be changed.

[mikehardy]

@iainmaryanow very interesting!
git blame is always the way to go diving in to answer your questions:
https://github.com/react-native-share/react-native-share/blame/main/android/src/main/java/cl/json/social/TargetChosenReceiver.java#L54

Looks like:
1- immutable flag needed for new platform #1077
2- class required to comply with security guidance / play store rejection #1046

[iimry]

Thanks @mikehardy, I appreciate the quick response.

I understand why #1 is necessary, however, I cannot find anywhere why adding this flag is causing the onReceive method not to be called. From what I find online, the two flags should be compatible.

For #2, I don't see why this was necessary for the remediation as it does not say to set the class, only the action, package, and component.

In either case, I am quite stumped how this is silently breaking the behavior as I don't really know much about Android development beyond what I've looked at for this issue.

The only other thing I can think of is using registerForActivityResult since startActivityForResult is deprecated. However, other issues already exist saying it can't be done at the moment due to something with react-native.

[mikehardy]

Well, for my part, as long as we don't suffer app store rejections (pending intent vulnerability), and work on API32 (immutable flag), anything that fixes the feature would be welcome 😅

[vladimirevstratov]

also Share.open always returns rejected error on telegram share
[Error: User did not share]

[ahtokca]

same here always 'User did not share' on android

[Maker-Mark]

This is still an issue :/

[shahmargi12]

I am also facing same issue. any update on how to fix it or any work around?

[karimelsaidy]

also facing same issue
react-native : 0.72.4
"react-native-share": "^9.3.0",

[Nachox07]

Same issue with these versions when content is shared in Telegram or Discord.

"react-native": "0.72.4",
"react-native-share": "^9.4.1"

[tpetrew]

Still this issue

[kenyipp]

Still this issue

[rjuevesano]

any updates?

[Gavru4]

Still this issue