Closed Bug 1802109 Opened 2 years ago Closed 2 years ago

The ETP is still disabled after the user is signed out

Categories

(Focus :: General, defect, P2)

Firefox 106
ARM64
Android
defect

Tracking

(firefox107 wontfix, firefox108 wontfix, firefox109 fix-optional)

RESOLVED INVALID
Tracking Status
firefox107 --- wontfix
firefox108 --- wontfix
firefox109 --- fix-optional

People

(Reporter: mlobontiuroman, Unassigned)

Details

(Keywords: regression)

Steps to reproduce

  1. Go to google.com, and sign in with valid credentials.
  2. Tap on the shield icon, and turn the ETP toggle OFF.
  3. Tap on the trashcan icon.
  4. Go to google.com again, and observe if the user is still signed in.
  5. Observe the ETP shield if it is still cut OFF (disabled).

Expected behavior

The user is signed out. The ETP shield is not cut OFF.

Actual behavior

The ETP shield is cut OFF, even though the user is no longer signed in.

Device information

Android device: Google Pixel 6 (Android 13)
Focus version: all
Regression range:

Severity: -- → S3
Keywords: regression

Chris, we're missing a regressing bug here so doubtful this will get any traction. Thoughts on what to do with this bug? It doesn't sound very serious, maybe we could go with fix-optional on 109 to get to bots off it.

Flags: needinfo?(cpeterson)

(In reply to Jim Mathies [:jimm] from comment #1)

Chris, we're missing a regressing bug here so doubtful this will get any traction. Thoughts on what to do with this bug? It doesn't sound very serious, maybe we could go with fix-optional on 109 to get to bots off it.

I'll set 109=fix-optional.

This is a privacy leak because Focus is remembering per-site ETP settings even after force-killing the app. So someone using your phone can see which sites you've visited (and happened to disable ETP for).

Regression range:

This regression range points to Focus 98 on 2022-01-25. Here are the Focus commits from 2022-01-25:

https://github.com/mozilla-mobile/focus-android/commits/main?after=84260abc8714a8650b9fb7968ccf50e3b4c4c24a+1124&branch=main&qualified_name=refs%2Fheads%2Fmain

Nothing looks suspicious that day, other than three A-C updates. Here are the A-C commits from 2022-01-25:

https://github.com/mozilla-mobile/android-components/commits/main?before=bb489ef682b33e8ebc770908bfe06befb13b0dd6+990&branch=main&qualified_name=refs%2Fheads%2Fmain

Nothing looks suspicious, so we'll need an Android engineer to debug this.

Flags: needinfo?(cpeterson) → needinfo?(mirabela.lobontiu)
Priority: -- → P2
Version: Firefox 109 → Firefox 106

Mihai, please take a look at this issue.
Thank you!

Flags: needinfo?(mirabela.lobontiu) → needinfo?(mcarare)

This looks like it was an intentional change.

The original request was this: https://bugzilla.mozilla.org/show_bug.cgi?id=1714945., based on this ticket: https://github.com/mozilla-mobile/focus-android/issues/4730

A whole new API was designed specifically for this purpose and then integrated into Focus through AC:

https://github.com/mozilla-mobile/focus-android/issues/5728
https://github.com/mozilla-mobile/android-components/pull/11190

It can be easily fixed, but we need confirmation (from Product?) what is the expected result. Should we persist with the setting or not?

Note that AFAIK in Fenix and desktop we do not persist the setting, but Focus might have a reasonable use case for this (i.e.: Not having to always disable it for a broken site that you visit often). I added this topic to tomorrow's sync with Product.

Flags: needinfo?(mcarare)
Flags: needinfo?(rtestard)

Note that AFAIK in Fenix and desktop we do not persist the setting, but Focus might have a reasonable use case for this (i.e.: Not having to always disable it for a broken site that you visit often). I added this topic to tomorrow's sync with Product.

+1 on this. For Focus it makes sense so users can persist the setting at all. However on Desktop these PBM setting should not persist.

I agree that we should retain this capability as is, as a way to let users mitigate web breakage that could prevent them from using Focus.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(rtestard)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.