Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

For #18727: Exit PiP when launched externally with Intents #20486

Closed
wants to merge 4 commits into from

Conversation

czlucius
Copy link
Contributor

@czlucius czlucius commented Jul 23, 2021

Linked issue: #18727

Adds exit PiP code in HomeFragment, exiting PiP on onCreate.

To check:

  • App doesn't exit PiP when in PiP and screen rotates
  • Check that intent in HomeActivity isn't null before exiting

Pull Request checklist

  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not
  • Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features. In addition, it includes a screenshot of a successful accessibility scan to ensure no new defects are added to the product.

To download an APK when reviewing a PR:

  1. click on Show All Checks,
  2. click Details next to "Taskcluster (pull_request)" after it appears and then finishes with a green checkmark,
  3. click on the "Fenix - assemble" task, then click "Run Artifacts".
  4. the APK links should be on the left side of the screen, named for each CPU architecture

Video of the fixed issue:

Screen_Recording_20210724-112718_Firefox.Preview.mp4

@czlucius czlucius requested review from a team as code owners July 23, 2021 17:14
@firefoxci-taskcluster
Copy link

No Taskcluster jobs started for this pull request
The `allowPullRequests` configuration for this repository (in `.taskcluster.yml` on the
default branch) does not allow starting tasks for this pull request.

@czlucius czlucius marked this pull request as draft July 23, 2021 17:14
@czlucius czlucius changed the title Exit PiP in HomeActivity after onCreate, addressing #18727 For #18727 Jul 23, 2021
@czlucius czlucius changed the title For #18727 For #18727: Exit PiP when launched externally with Intents Jul 23, 2021
@czlucius
Copy link
Contributor Author

Screen_Recording_20210724-112718_Firefox.Preview.mp4

Here's the video of the fixed issue. Tested on Android 11 on Samsung P610 (Tab S6 Lite).
I'll need to investigate into the possible side effects first.

@Mugurell
Copy link
Contributor

Mugurell commented Aug 6, 2021

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.
Curious if @mcomella agrees with the this approach from a performance standpoint.

Copy link
Contributor

@mcomella mcomella left a 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))
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@czlucius czlucius marked this pull request as ready for review August 8, 2021 11:22
@Mugurell
Copy link
Contributor

Mugurell commented Aug 11, 2021

Remembered we were doing something similar on Fennec also.
Speaking of which, @czlucius can we change to use FLAG_ACTIVITY_REORDER_TO_FRONT as the flag for the startActivity Intent? Seems more appropriate than FLAG_ACTIVITY_NEW_TASK.
Then we can give this a shot in the new 93 train.

Mugurell
Mugurell previously approved these changes Aug 13, 2021
@czlucius
Copy link
Contributor Author

Sorry, I forgot to add the import statement before.

@czlucius
Copy link
Contributor Author

I've tested the fix with the new flag, it seems to work fine.

@Mugurell Mugurell added the pr:needs-landing-squashed PRs that are ready to land (squashed) [Will be merged by Mergify] label Aug 13, 2021
@Mugurell
Copy link
Contributor

@Mergifyio refresh

@mergify
Copy link
Contributor

mergify bot commented Aug 16, 2021

Command refresh: success

Pull request refreshed

@Mugurell
Copy link
Contributor

@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.
Can you please squash your work and rebase on the latest main to then try to merge it again?

@Mugurell Mugurell closed this Aug 16, 2021
@Mugurell Mugurell reopened this Aug 16, 2021
@czlucius
Copy link
Contributor Author

czlucius commented Aug 16, 2021

Ok, I’ll try. Do you mean squash my commits into 1 commit then rebase into the main branch?

@czlucius
Copy link
Contributor Author

czlucius commented Aug 16, 2021

I'll try soon, but lately I've been quite busy, will do soon when I'm free
Thanks

@Mugurell
Copy link
Contributor

Ok, I’ll try. Do you mean squash my commits into 1 commit then rebase into the main branch?

Yes. Thank you!

@czlucius
Copy link
Contributor Author

Ok.

Copy link
Contributor Author

@czlucius czlucius left a 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

@Mugurell
Copy link
Contributor

@czlucius The indentation seems fine but detekt is failing because the onCreate method is not too complex - with the if block added by this patch there are too many branches.
The easiest (and probably the best here) solution is to just add the @Suppress("ComplexMethod") annotation to onCreate.

You can also run detekt and ktlint locally with
./gradlew detekt && ./gradlew ktlint to check everything is ok.

@czlucius
Copy link
Contributor Author

Ok, I will make these changes.
On a side note, would it be ok to extract the code exiting PiP into a function to reduce ˋonCreateˋ's complexity?

Thanks.

@Mugurell
Copy link
Contributor

On a side note, would it be ok to extract the code exiting PiP into a function to reduce ˋonCreateˋ's complexity?

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 👍.
Maybe something like checkAndExitPip?

@czlucius
Copy link
Contributor Author

czlucius commented Aug 31, 2021

I've made the relevant changes, if dekekt still shows errors, I will replace this with the @Suppress solution.

@Mugurell
Copy link
Contributor

@czlucius Sorry for this being a drag but now it seems the ktlint task is failing because of

/home/runner/work/fenix/fenix/app/src/main/java/org/mozilla/fenix/HomeActivity.kt:273:1: Needless blank line(s)
/home/runner/work/fenix/fenix/app/src/main/java/org/mozilla/fenix/HomeActivity.kt:276:1: Unexpected indentation (9) (should be 8)

@czlucius
Copy link
Contributor Author

screenshot-77b9fe3b

ktlint seems to be ok with this locally.

@czlucius czlucius force-pushed the fix-issue-18727 branch 2 times, most recently from 0ee8b18 to 56610ec Compare August 31, 2021 15:25
@Mugurell
Copy link
Contributor

ktlint seems to be ok with this locally.

That warning can be ignored for now.
But I see in the CI tasks ktlint failing because of

/home/runner/work/fenix/fenix/app/src/main/java/org/mozilla/fenix/HomeActivity.kt:273:1: Needless blank line(s)

With this also fixed we can look into merging the patch.

@czlucius
Copy link
Contributor Author

czlucius commented Sep 1, 2021

ktlint is ok, but now a test is failing (hence test-debug fails)

SmartSelect_20210901-115927_Samsung Internet.jpg

@Mugurell
Copy link
Contributor

Mugurell commented Sep 1, 2021

With everything green I think we can merge this.

@czlucius
Copy link
Contributor Author

czlucius commented Sep 1, 2021

@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.
Thanks.

@pocmo pocmo removed the pr:needs-landing-squashed PRs that are ready to land (squashed) [Will be merged by Mergify] label Sep 2, 2021
@Mugurell
Copy link
Contributor

Mugurell commented Sep 2, 2021

@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.
Thanks.

Don't think there is any change for the activity while in PiP though?
Nothing changes about it. Still in foreground but in the onPause state Android puts it in for the entire duration of PiP.
From here it would either get onResume if returning to the app or onStop if PiP and the activity is closed.

@Mugurell
Copy link
Contributor

Mugurell commented Sep 2, 2021

#20831 merged these changes so I'll close the PR.
Thank you @czlucius !

@Mugurell Mugurell closed this Sep 2, 2021
@czlucius
Copy link
Contributor Author

czlucius commented Sep 2, 2021

Thank you @czlucius !

Welcome.

Thank you for merging the fix.

@czlucius
Copy link
Contributor Author

czlucius commented Sep 2, 2021

Don't think there is any change for the activity while in PiP though?
Nothing changes about it. Still in foreground but in the onPause state Android puts it in for the entire duration of PiP.
From here it would either get onResume if returning to the app or onStop if PiP and the activity is closed.

Noted.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants