You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
Fix Bot
committed
Fix: retry onFreedomPurchaseStateChanged delivery to survive WebView-not-ready race
Root cause found: evaluateWebViewJs() silently no-ops if webViewInstance is
null or the page/JS context isn't fully attached at that exact moment
(webViewInstance?.post{...} just does nothing). The Freedom purchase
callback was previously fired exactly once, right when Google Play's
billing callback returns - often right as the Activity is still
transitioning back from the Play billing bottom sheet, i.e. exactly when
the WebView is least likely to be reliably attached.
If that single delivery was dropped, nothing resent it: queryActiveSubscriptions()
on the next onResume only re-sends the callback when
'!TrialManager.isFreedomPurchased(this)' - but the native flag was already
set to true by the original (dropped) handlePurchase() call, so that guard
silently prevented any retry. The WebView was then stuck showing the
Pro-only UI until a full app restart, where onAndroidReady's parameterless
updateDonationCard() finally read the correct native state fresh.
Fix: new evaluateWebViewJsWithRetry() re-sends the same JS up to 5 times
over ~2 seconds. All 4 call sites for onFreedomPurchaseStateChanged now use
it, so a dropped first delivery is very likely followed by a successful one
shortly after, without requiring the user to restart the app.
if (TrialManager.isPurchased(this@MainActivity)) {
1401
1401
Log.w(TAG, "queryActiveSubscriptions: No active subscription found by Google Play Billing, but app was previously marked as purchased. Clearing purchase mark.")
@@ -1701,6 +1701,27 @@ class MainActivity : ComponentActivity() {
1701
1701
}
1702
1702
}
1703
1703
1704
+
/**
1705
+
* Like [evaluateWebViewJs], but re-sends the same JS a few times with a delay in between.
1706
+
*
1707
+
* Purchase-completion callbacks (e.g. window.onFreedomPurchaseStateChanged) were previously
1708
+
* sent exactly once, right when Google Play's billing callback fires. If webViewInstance was
1709
+
* null or the page/JS wasn't fully attached yet at that exact moment (e.g. because the
1710
+
* Activity was still transitioning back from the Play billing sheet), the single
1711
+
* evaluateJavascript call was silently dropped and the WebView kept showing the old
1712
+
* (pre-purchase) state until the next full app restart, even though the native purchase
1713
+
* flag was already set correctly. Retrying a few times over a couple of seconds makes
1714
+
* delivery robust without needing a full native rewrite of the purchase flow.
0 commit comments