Closed jonalmeida closed 5 years ago
Looks like when the issue happens we are getting a indirect intent to BrowserActivity
instead of to IntentReceiverActivity
.
The weird thing is that IntentReceiverActivity
has all the intent filters to be called for this action (android.intent.action.VIEW)
@jonalmeida and I spent the day debugging this issue 🙃 but It was fun :)
What we found is the following:
1. The Twitter app supports custom tabs and its trying to open the links as custom tabs e.g they call warmup
on RB, but when they create the intent, they are not including the extra flag CustomTabsIntent.EXTRA_SESSION
android.support.customtabs.extra.SESSION
this extra flag identifies custom tabs, and as a result we are not treating the Twitter intents as custom tabs.
The weird part is that they are only including the extra flag, when the default browser is Chrome or FireFox . We could confirm the issue because we changed locally the applicationId
of RB to org.mozilla.firefox
and we saw that they send us the flag and RB treated the intent as a custom tab.
2. From what I've saw, the issue is happening because the only place where we are handling intents is IntentReceiverActivity
. There we use intentProcessor
for creating a session from the intents and routing the intents to a custom tab or a normal browser experience.
When the issue happens the intent from Twitter is never hitting IntentReceiverActivity
is going directly to BrowserActivity
as result, the link is not loading, because IntentReceiverActivity
is the only one that knows how to create a session from an intent. We were expecting that an intent always must go first to IntentReceiverActivity
and after that to BrowserActivity
as we configured the intent-filter
for that in theAndroidManifest.xml
file.
I could confirm that because, I added logs statements in both IntentReceiverActivity
and BrowserActivity
. But when the issue happens the logs on IntentReceiverActivity
never get executed just the one from BrowserActivity
. In addition to that, I added break points to both classes and when the issue occurs just the one on BrowserActivity
are getting called.
I suppose this is happening as a side effect of a non-standard implementation . With custom tabs I could replicate the issue. Even @jonalmeida and I could replicate the issue on Focus.
I believe the ActivityManager
is getting confused by a non-standard implementation of custom tabs.
✅ These are logs from ActivityManager
when the link gets loaded.
IntentReceiverActivity
gets called, it creates the session and forwards the call to BrowserActivity
that loads the link.
My logs get printed and the break points in both classes get hit ✅
2019-02-27 21:01:40.121 1187-1531/? I/ActivityManager: START u0 {act=android.intent.action.VIEW dat=https://t.co/... flg=0x10000000 cmp=org.mozilla.reference.browser/.IntentReceiverActivity (has extras)} from uid 10184
2019-02-27 21:01:40.201 1187-1531/? I/ActivityManager: START u0 {act=android.intent.action.VIEW dat=https://t.co/... flg=0x10400000 cmp=org.mozilla.reference.browser/.BrowserActivity (has extras)} from uid 10279
2019-02-27 21:01:40.205 1187-1531/? W/ActivityManager: Duplicate finish request for ActivityRecord{511a54c u0 org.mozilla.reference.browser/.IntentReceiverActivity t14329 f}
2019-02-27 21:01:40.291 1187-1230/? I/ActivityManager: Displayed org.mozilla.reference.browser/.IntentReceiverActivity: +144ms
🔴 When the issue happens I get these logs from ActivityManager
,
It says that only class called was IntentReceiverActivity
but my logs on it, never get printed neither my break points get hit. But my logs on BrowserActivity
get printed and my break points get hit 🙃
2019-02-27 20:58:43.877 1187-4749/? I/ActivityManager: START u0 {act=android.intent.action.VIEW dat=https://t.co/... flg=0x10000000 cmp=org.mozilla.reference.browser/.IntentReceiverActivity (has extras)} from uid 10184
A video when the issue happens and we press a different link from the one that caused the issue. it looks like ActivityManager
is sending the same intent for just that link.
@pocmo as you have more experience with custom tabs what do you think?
What can we do from here? We have to notify the Twitter android dev about the issue, because only Chrome and FireFox are going to be able to use custom tabs on their app.
To mitigate the issue, we could add a double check condition on BrowserActivity
to verify if we have an intent that hasn't been processed by intentProcessor
we have to process it.
STR:
There are a couple of linked issues here that are related and can possibly make the situation better if fixed.
they are not including the extra flag CustomTabsIntent.EXTRA_SESSION android.support.customtabs.extra.SESSION
To clarify, the calling app doesn't set this extra, the support library does this when a CustomTab intent is created and sent.
I've reached out to a Twitter Android dev about this issue! :)
I've reached out to a Twitter Android dev about this issue! :)
@ekager Did you get a response from the Twitter Android dev? :)
To update this ticket: our custom tabs support is in a much better state now so we aren't seeing the many of the original side-effects, but it would be nice to not be filtered out of Custom Tab support from Twitter - we handle those links as regular ones.
The ticket has been assigned on their end and I will update when there is more information
Twitter 8.4.0-alpha.120 has the fix to use the default browser for invoking Custom Tabs.
We can close this ticket now! 👏 🎉
Steps to reproduce
Expected behavior
Actual behavior
Device information
These STR aren't very accurate though because it seems to happen if r-b is recently opened and in-memory for it to be reproducible. Once in that state, I can see the issue consistently.
Once I swipe away the app and try it again, the link loads without any hitches.
Below is log when a link in Twitter is clicked:
And after r-b is swiped away, the expected logs: