1979823 - Move PrivateBrowsingLockFeature initialization to the HomeActivity

Status: RESOLVED FIXED

(Firefox for Android :: Privacy, task)

Description

[Jonathan Almeida [:jonalmeida]]

The PrivateBrowsingLockFeature is meant to live the lifetime of the host activity (HomeActivity) which is where it is also initialized, but we keep it in Components.kt which makes the feature live the lifetime of the application.

Lets move the initialization code to where it currently happens to avoid side-effects of instances living longer than they should.

Comment 1

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1979823 - Move PrivateBrowsingLockFeature constructor to where it happens r=twhite,mavduevskiy

The PrivateBrowsingLockFeature lives longer that the activity it is
attached too, so lets keep the scope the same.

Added a PrivateBrowsingLockUseCases to follow our use case patterns
that replaces the onSuccessfulAuthentication which doesn't need to be
coupled together since it only dispatches to the AppStore.

Comment 2

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1979823 - Move PrivateBrowsingLockFeature constructor to where it happens r=twhite,mavduevskiy

The PrivateBrowsingLockFeature lives longer that the activity it is
attached too, so lets keep the scope the same.

Added a PrivateBrowsingLockUseCases to follow our use case patterns
that replaces the onSuccessfulAuthentication which doesn't need to be
coupled together since it only dispatches to the AppStore.

Comment 3

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1979823 - Update tests in PrivateBrowsingLockFeatureTest using UseCase r=twhite,mavduevskiy

Comment 4

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1979823 - Fix setting initial state of PrivateBrowsingLockFeature r=twhite,mavduevskiy

Now that we aren't using the application instance of the feature to hold
our state, we should read the AppStore value during init similar to our
persisted feature enabled flag.

We don't really need to check whether there are private tabs AND
isPrivateScreenLocked because private tabs are never persisted, but I
left that original logic in there because it doesn't seem to hurt to
have it.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a809809198bc
https://hg.mozilla.org/integration/autoland/rev/7f6b6ba39c8e
Move PrivateBrowsingLockFeature constructor to where it happens r=twhite,android-reviewers
https://github.com/mozilla-firefox/firefox/commit/00805e51211a
https://hg.mozilla.org/integration/autoland/rev/e3e1d1b06d94
Update tests in PrivateBrowsingLockFeatureTest using UseCase r=twhite,android-reviewers
https://github.com/mozilla-firefox/firefox/commit/b179442bef84
https://hg.mozilla.org/integration/autoland/rev/5d50e131c5a8
Fix setting initial state of PrivateBrowsingLockFeature r=twhite,android-reviewers

Comment 6

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/7f6b6ba39c8e
https://hg.mozilla.org/mozilla-central/rev/e3e1d1b06d94
https://hg.mozilla.org/mozilla-central/rev/5d50e131c5a8