Recently closed tabs are shown even when history preference is set to 'never remember history'
Categories
(Firefox :: Session Restore, defect, P3)
Tracking
()
People
(Reporter: bugger, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-fxview-polish])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0
Steps to reproduce:
Turned off FIrefox (desktop) history and navigated to the 'Firefox View' tabl
Actual results:
The Firefox view tab includes history (even though turned off in browser and doesn't show up in history)
Expected results:
Firefox from a device with history turned off should not be included in the Firefox view, this is not communicated to users and seems to leak browser history even though history is turned off.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Firefox View' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Hello, thank you for the bug report!
Do you mean that Firefox View displays tabs in the Recently Closed Tabs section whilst it is running? Are the tabs still visible after exiting and opening Firefox again?
Comment 3•2 years ago
|
||
In addition to Ardelean's question, can you please clarify the steps to reproduce. Did you go into about:preferences and change "Firefox will remember history" to "never remember history", which causes the browser to restart before you can change to another tab? If not, what specific action did you take?
Steps to reproduce:
- Open a private window. Alternatively, set to
never remember history
and restart browser. - Open 2 tabs. (So window is not closed after closing 1 tab)
- In 1 tab, go to any page. E.g. https://example.com/.
- Close this tab.
- In another tab, go to
about:firefoxview
.
Actual result:
example.com is shown in section Recently Closed. The entry is gone after closing this window (or in another window).
Comment 0's expected result:
example.com should not be shown at all.
The confusion may stem from:
- Users not realising that the section is about recently closed tabs and only in this window.
- Users not realising that Firefox's closed tabs history is kept until all private windows are closed (same for prema-private mode). Chrome does not allow reopening closed tabs in incognito mode.
- Conflicts between Library's history section (no entries) and Firefox View's Recently Closed section. (Though Firefox View is not showing histories.)
- Prema-private mode (never remember history) keeps the Firefox View button despite it does not show in private browsing windows (but still accessible via about:firefoxview).
Suggestions:
- Add an additional notice in the description when an user accesses Firefox View in private/perma-private mode. Or
- Remove Firefox View button in perma-private mode. Or
- Better explain how the section works in Firefox View support article.
The same issue was also raised on Reddit.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
•
|
||
Thanks for the STR. I can reproduce this issue, but it should probably focus on the original issue which was about setting history to never remember history
and still seeing closed tabs (not based on the private window and navigating to about:firefoxview, but it might be worth a separate bug).
This isn't an issue with Firefox View specifically but with Session Store, and I'm not sure if this was by design or not. If I look at the app menu > history and 'recently closed tabs' per the STR, I see a recently closed tab there too after changing the history to 'never remember history', not just in the Recently Closed section in firefox View. (I'll note though, that while my previous history is still present, I don't see new history entries being created.)
It would make sense to me that if you can clear history and recently closed tabs you shouldn't have recently closed tabs show up once you change this setting.
- Users not realising that the section is about recently closed tabs and only in this window.
The heading does say "Recently closed" with a caption of "Reopen pages you've closed in this window". But perhaps "pages" should be swapped out with "tabs".
Updated•2 years ago
|
Comment 6•2 years ago
|
||
Gijs or Dao, can you weigh in on my comment 5? If you think that this is expected behavior, we can close this out.
Comment 7•2 years ago
|
||
I think this is a dupe of bug 1796682.
Comment 8•2 years ago
|
||
Gijs and I talked about this. Its not a duplicate of bug 1796682, but a related issue with different settings checked that have resulted in confusion.
Comment 9•2 years ago
|
||
Hi this it the UX recommendation:
We show recently closed tabs in the menu bar and in Firefox View despite getting signals from users that they don’t want their history shown. This is evident in the following scenarios:
-
User sets their browsing history to “Never remember history” in settings under “Privacy & Security”.
-
User unchecks “Remember browsing and download history” under “Use custom settings for history”
-
User uses private browsing (users can see Firefox View if they type in “about:firefoxview” in a private window and see their recently closed tabs)
Hypothesis:
If a user choses to not want their browsing history saved, we assume they don’t want to see their recently closed tabs visible as well, especially on a high visible surface like Firefox View.
Recommendation:
If the user choses any of the above settings, we treat “recently closed tabs” the same way we treat “recently closed windows”. The menu item is greyed out in the menu bar and we don’t show recently closed tabs in Firefox View (empty state messaging TBD).
Please reach out to @mbruk for any follow-up UX questions. Thanks!
Comment 10•2 years ago
|
||
Thanks Amy! There's a separate bug 1796682 for the "Never remember history" in settings under "Privacy & Security" case. I'll leave it to the engineer assigned to this ticket to decide if the solution should be split out (each bug addressing the the different scenarios) rather than addressing all of the above in a single patch.
Updated•2 years ago
|
Comment 12•10 months ago
|
||
Recommendation:
If the user choses any of the above settings, we treat “recently closed tabs” the same way we treat “recently closed windows”. The menu item is greyed out in the menu bar and we don’t show recently closed tabs in Firefox View (empty state messaging TBD).
If I'm reading the UX recommendation correctly, we want to change Session Store behavior to not collect recently closed tabs and windows in all the private / never remember history scenarios. Note, that would also remove the "undo closed tab" feature from private windows. Having empty recently closed tabs and windows collections would automatically grey out those options in the history menu, and we would get the empty state in Firefox View, so I don't think there is any other UI work, though we might be able to trim some menu code and firefox view code that checks for conditions which would no longer be possible.
We have a number of tests that assert on the current behavior which would also need to be updated here - both for Session Store and Firefox View.
Comment 13•10 months ago
|
||
that sounds right to me sam! let me know if you need me to clarify anything
Comment 14•10 months ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #12)
Recommendation:
If the user choses any of the above settings, we treat “recently closed tabs” the same way we treat “recently closed windows”. The menu item is greyed out in the menu bar and we don’t show recently closed tabs in Firefox View (empty state messaging TBD).If I'm reading the UX recommendation correctly, we want to change Session Store behavior to not collect recently closed tabs and windows in all the private / never remember history scenarios. Note, that would also remove the "undo closed tab" feature from private windows.
Why do this for all private windows rather than only for permanent private browsing / "never remember history" mode?
(he says, as someone who definitely uses "undo close tab" in private windows. :-) )
Comment 15•10 months ago
|
||
(In reply to :Gijs (he/him) from comment #14)
Why do this for all private windows rather than only for permanent private browsing / "never remember history" mode?
(he says, as someone who definitely uses "undo close tab" in private windows. :-) )
I'm just re-summarizing UX' recommendation here to make sure we all understand the implications of that recommendation. I can totally see the utility of having undo close tab (or actually the whole list of recently closed tabs) in private windows as well as "never remember history mode". But we asked for guidance and guidance was delivered. Intuitively I'd think undo close tab might be even more missed in never remember history mode - where there aren't clear cues that you are in some special mode and people might expect the browser to operate as normal.
So we could just fix this for "never remember history" mode per this bug. But I'm not sure I could explain why the same shouldn't apply to private windows. How would you articulate the difference and different expectations in never remember history mode vs a private window?
Comment 16•10 months ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #15)
(In reply to :Gijs (he/him) from comment #14)
Why do this for all private windows rather than only for permanent private browsing / "never remember history" mode?
(he says, as someone who definitely uses "undo close tab" in private windows. :-) )I'm just re-summarizing UX' recommendation here to make sure we all understand the implications of that recommendation.
Ah, right, sorry - I read the last 2 comments but not comment #9.
So we could just fix this for "never remember history" mode per this bug. But I'm not sure I could explain why the same shouldn't apply to private windows. How would you articulate the difference and different expectations in never remember history mode vs a private window?
I think this is a fair point.
We've historically been pretty convinced that the existing behaviour is correct. Cf. bug 1274537 and all its dupes.
We've also broken this by accident at least twice, and fixed it (bug 961380, bug 832325).
ISTM that this bug is motivated by the added visibility of the Firefox View page. That is somewhat understandable, but (a) the user has to go to the trouble of manually opening the page in a private window as it's not there by default, so that doesn't feel like the "high visible surface" comment 9 describes and (b) the data has always been there, and as pointed out in bug 1274537, the data is still going to be there even if we don't save closed tabs in memory anymore in either permanent PB or in private windows. The cookies and permissions etc. will still remain in memory. So we're more effectively hiding traces of what the user did from that same user (or shoulder surfing), but we're not actually removing all of it immediately (and doing so would be a much bigger job). For users who want this, we're building a separate button that clears private browsing information while the session is open.
We also rely on "undo close tab" as a recovery method for accidental clicks, and that was a justification for removing "are you sure" style dialogs from the default configuration of Firefox.
The motivation in comment 9 is about the visibility of information; breaking the functionality everywhere feels a bit baby/bathwater to me. But as you say, it's the logical consequence of hiding the information in the existing UI; it would be a bit inconsistent to hide the section in Firefox View and not in other pieces of UI.
All that said, Chrome, Edge and Safari all do not allow this, so perhaps it's just time to align with them? (Though I'm sure that if we do change this, we'll get write-ins from people who use the current state and will be unhappy at the dataloss.)
Description
•