Closed Bug 1485743 Opened Last year Closed Last year

"New in Nightly: Content Blocking" walk through popups step 1 and 2 shown together

Categories

(Firefox :: Protections UI, defect, P1)

63 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
firefox63 + verified

People

(Reporter: haik, Assigned: johannh)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

With the new "New in Nightly: Content Blocking" intro, after clicking Next on step 1, a new tab is created showing both "1 or 3" and "2 of 3" dialogs on the same page.

Additionally, after clicking "Got it" on step 3, the into went back to step 2. The second time it went to step 3, clicking "Got it" worked.

Hit on macOS 10.13.

See attached image with sequence of screenshots.
Johann, I assume this is something we want to fix for 63?
Flags: needinfo?(jhofmann)
Yes, though I assume it's only happening in private windows, is that correct?
Flags: needinfo?(jhofmann)
Flags: needinfo?(haftandilian)
(In reply to Johann Hofmann [:johannh] from comment #2)
> Yes, though I assume it's only happening in private windows, is that correct?

Correct. I tried reproducing this on a normal window and could not.
Flags: needinfo?(haftandilian)
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Priority: -- → P1
So, currently, we're not setting the "has seen the UI tour" pref in private windows, which is the reason for any issues I've seen so far. To fix this we have a bunch of options:

- Don't show the UI tour in private browsing. This would follow the previous rule of not showing the TP tour in private windows and I think it's a sensible choice, since pb mode can be an environment where users probably don't appreciate interruptions.

- Set the pref after the user has seen the tour in private windows. This would be an easy fix and we could continue showing the UI tour in private windows. This could very hypothetically leak the fact that the user visited a tracking page in private browsing, though I think that's not a very strong risk. As I mentioned above, it may be that users are more likely to just dismiss the tour when they are in private windows.

- Set an in-memory flag that only remembers the UI tour showing for the private window, to circumvent the problems described above.

IMO the first option sounds best, and I'll make a patch for that.
Comment on attachment 9003742 [details]
Bug 1485743 - Don't show the Content Blocking tour in private windows. r=francois

François Marier [:francois] has approved the revision.
Attachment #9003742 - Flags: review+
Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/258c008b1915
Don't show the Content Blocking tour in private windows. r=francois
https://hg.mozilla.org/mozilla-central/rev/258c008b1915
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
I reproduced this issue using Fx 63.0a1(2018-08-23) on macOS 10.13.6.
I can confirm this issue is fixed, I verified using Fx 63.0a1(2018-08-27), on Windows 10 x64, macOS 10.13 and Ubuntu 14.04 LTS.
You need to log in before you can comment on or make changes to this bug.