Forget About this Site doesn't close open tabs

NEW
Unassigned

Status

()

Toolkit
Forget About Site
9 years ago
2 years ago

People

(Reporter: beltzner, Unassigned)

Tracking

(Depends on: 1 bug, {privacy})

Trunk
privacy
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

STR:

1. Go to www.beltzner.ca/mike
2. History > Show all History
3. Find beltzner.ca and right-click
4. Select "Forget About this Site"

Expected: any tab open with beltzner.ca would close

Actual: abs open with beltzner.ca stay open
Flags: blocking-firefox3.1?
Spun off from bug 464199 comment 2

The following cases must be considered:

 - what happens if closing these tabs ends up closing all the tabs in a window?
 - what happens if closing these tabs ends up closing all open tabs (thus closing the browser on w32)?
Not blocking as we don't yet have the method being called from the site identity button, and I think that despite Alex's assertion, users will understand a reluctance to close tabs from underneath of one's self.

I do still think this should be fixed, just wouldn't hold the release for it.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-

Comment 3

9 years ago
We still don't have a "Firefox:Browser Glue" component...
Component: Session Restore → General
QA Contact: session.restore → general
So, I had actually asked about this when I was implementing it, and mconnor had said to leave the tab open.
I think all the arguments in favor of clearing history but not the session are based on understanding the implementation model of these things being different.  Also, what is the actual use case for the user saying "do not remember anything about this site, clear everything" and then actually wanting the tabs to still be open?

Comment 6

9 years ago
Closing the tabs might surprise users in a bad way.  How about asking users if they want the tabs to be closed?
Depends on: 460086
If 90% of users think clearing history is "removing all evidence" and not "clearing places.sqlite but not sessionstore.js" then I think we should just remove all the evidence.  I honestly can't think of a reason for someone to want to selectively clear everything.  They might find the tab closing surprising the first time, but I don't think the behavior is unwanted, but is actually surprisingly convenient.
(In reply to comment #6)
> Closing the tabs might surprise users in a bad way.  How about asking users if
> they want the tabs to be closed?

As it stands now, if this will cause multiple tabs to close the "Are you sure you want to close n tabs" dialog will popup anyhow, the question is when one tab is closed, should there be a warning? IMHO there should not be, but let's see what ux has to say about that.
I think I was being conservative, but we should just close the tabs.  We have undo close tab, so unless it's closing a window I think we should just close without asking.

Shawn, make it so? :)
Assignee: nobody → sdwilsh

Comment 10

9 years ago
> We have undo close tab

But surely "Forget About this Site" removes sites from this location as well, for privacy reasons?
(In reply to comment #10)
> But surely "Forget About this Site" removes sites from this location as well,
> for privacy reasons?
probably not...

Comment 12

9 years ago
So what about bug 464199?
(In reply to comment #12)
> So what about bug 464199?
I didn't know about that one.  With this and that, we should be OK (as long as this runs before that)

Comment 14

9 years ago
It seems odd that in other bugs, FAtS goes through lots of trouble to remove local data about the site from hidden places, but in this bug, the proposal is for FAtS to move data from an obvious place (an open tab) to a non-obvious place (the undo close tab list).

I think that when there are tabs for the site open, we should make users click twice: once on a button labeled "close 2 tabs", and then on a button labeled "forget about this site".
(In reply to comment #14)
> It seems odd that in other bugs, FAtS goes through lots of trouble to remove
> local data about the site from hidden places, but in this bug, the proposal is
> for FAtS to move data from an obvious place (an open tab) to a non-obvious
> place (the undo close tab list).
Bug 464199 also removes it from that non-obvious place, so I'm not sure what the issue is.
In the context that this feature is designed to destroy data, we should be more worried about what is preserved as opposed to what is removed.  Since we can't support and undo (without first preserving information), what about a single confirmation prompt that lists how many history visits and open tabs will be cleared.  This has the added benefit of giving us a little more room to describe what is going to happen.

Updated

8 years ago
Assignee: sdwilsh → nobody

Comment 17

7 years ago
i navigated to an innocent url but the criminating evidence still remained in the tab history (back-forward context menu)
even if we do not close the tab, i think the back-forward context menu should be purged for the offending urls. should i open a new bug for this?

Updated

7 years ago
Keywords: privacy
Yes, please do.

Updated

7 years ago
Depends on: 606403

Updated

4 years ago
Component: General → Forget About Site
Flags: wanted-firefox3.5+
Flags: blocking-firefox3.5-
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.