-
Notifications
You must be signed in to change notification settings - Fork 1.3k
For #18727: Exit PiP when launched externally with Intents #20486
Conversation
No Taskcluster jobs started for this pull requestThe `allowPullRequests` configuration for this repository (in `.taskcluster.yml` on the
default branch) does not allow starting tasks for this pull request. |
Screen_Recording_20210724-112718_Firefox.Preview.mp4Here's the video of the fixed issue. Tested on Android 11 on Samsung P610 (Tab S6 Lite). |
To me this looks good. We obtain the desired effect and seems the generally accepted solution in place of an official Android api for this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if @mcomella agrees with the this approach from a performance standpoint.
Thanks for looping me in. From a perf perspective, I was concerned about HomeActivity.onCreate
getting called twice but that doesn't seem to be the case. Subjectively, I tested on a Moto G5 and it doesn't seem unreasonable. It'd take too long for me to objectively benchmark the change because it doesn't have a clear start and ending point so I'll say this seems reasonable from a perf perspective.
From a correctness perspective, I'm wary about triggering the android lifecycle unnecessarily. It's difficult to code correctly around the common lifecycle patterns but the Android framework does unexpected things when we're intentionally recreating activities to reset state. For example, we use activity.recreate()
to switch between normal and private browsing and it calls unexpected code paths such as HomeFragment.onCreateView being called before HomeActivity.onCreate even inflates the layout containing HomeFragment
(because Android is automatically restoring the fragment stack without us having to inflate and define the state).
That being said, I don't know what moveTaskToBack(...); startActivity(... this)
does specifically, it may be simpler than the activity.recreate
case, and it may be the right solution for the problem here. I didn't look at this carefully from the correctness perspective but I just wanted to mention my general preference for finding solutions that don't trigger the lifecycle rather than ones that do. So I'm not blocking the review on this – thanks for the patch!
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N && isInPictureInPictureMode) { | ||
// Exit PiP mode | ||
moveTaskToBack(false) | ||
startActivity(Intent(this, this::class.java).addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue (non-blocking): I'm not sure how results in us exiting PiP mode.
suggestion: can you explain in the comment how this lets us exit PiP mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://stackoverflow.com/a/43288507/12204281
The code moves the activity to the back of the activity stack, then restores it to the front, bringing it out of PiP mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand why moving the activity to the back of the activity stack and restoring it to the front would bring it out of PiP – it seems like it might be a hack. However, if it seems like this is the only way to do it, I'm fine with that – just link to the Stackoverflow post in a comment so others have context on where this solution came from.
In any case, I don't need to approve or reject the correctness changes: I'll defer to @Mugurell for those. @Mugurell Please finish reviewing – it looks good from my perspective on performance! Sorry if I was unclear about my intent.
Remembered we were doing something similar on Fennec also. |
ee051e3
to
31fac79
Compare
Sorry, I forgot to add the import statement before. |
I've tested the fix with the new flag, it seems to work fine. |
@Mergifyio refresh |
Command
|
@czlucius It seems there is an issue with the script we're using for landing PRs and right now this PR is also blocking others from landing so I'll close this just to let the others pass. |
Ok, I’ll try. Do you mean squash my commits into 1 commit then rebase into the main branch? |
I'll try soon, but lately I've been quite busy, will do soon when I'm free |
Yes. Thank you! |
5e70c2e
to
d6d9378
Compare
Ok. |
003aee5
to
7f159cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope the indentation is fine
@czlucius The indentation seems fine but You can also run detekt and ktlint locally with |
Ok, I will make these changes. Thanks. |
Having that code in onCreate makes it easier to follow but if the new method has an enough of a suggestive name that would work also 👍. |
7f159cb
to
1996f67
Compare
I've made the relevant changes, if |
@czlucius Sorry for this being a drag but now it seems the
|
1996f67
to
6ab633c
Compare
0ee8b18
to
56610ec
Compare
That warning can be ignored for now.
With this also fixed we can look into merging the patch. |
56610ec
to
75acc52
Compare
With everything green I think we can merge this. |
@Mugurell may I ask, if in PiP, the activity still undergoes lifecycle changes? I did not see anything anywhere on the Android Developer website, nor on Stackoverflow that suggests this, but just to be sure. |
Don't think there is any change for the activity while in PiP though? |
Welcome. Thank you for merging the fix. |
Noted. |
Linked issue: #18727
Adds exit PiP code in
HomeFragment
, exiting PiP ononCreate
.To check:
HomeActivity
isn't null before exitingPull Request checklist
To download an APK when reviewing a PR:
Video of the fixed issue:
Screen_Recording_20210724-112718_Firefox.Preview.mp4