Closed Bug 1020539 Opened 5 years ago Closed 5 years ago

about:networking hostname list not clearing after deleting history

Categories

(Core :: Networking, defect)

32 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla33
Tracking Status
firefox29 --- wontfix
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- verified
firefox33 --- verified
firefox-esr24 --- wontfix

People

(Reporter: sirpfremmer, Assigned: valentin)

Details

(Keywords: privacy, regression, verifyme)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140604030202

Steps to reproduce:

1.)  Navigate to several URLs
2.)  Open about:networking
3.)  Select all tickboxes in the Clear All History dialogue
4.)  Refresh/reload about:networking


Actual results:

The list of hostnames persists.  This occurs in safe mode as well.


Expected results:

All stored history should be cleared via the menu, as per the 'Browsing and Download History' tickbox.  This is otherwise an uncomfortable privacy issue.
Hi,

I was able to reproduce it on latest Nightly Firefox/32.0 ID:20140604030202 on Debian Sid x86_64. The about:networking page still show the very same data even after clearing all browsing history (even selecting the "Everything" option and checking all the boxes). Clearing the history and then restarting the browser (quitting it and then launching it again) seems to work, though (ie: after that about:networking is empty).

Happens also with a clean profile, and affects latest Nightly, latest Aurora (31.0a2 2014-06-04) and latest Beta (30 20140603140158).

Let me know if you need more info.

Cheers,
Francesca
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
OS: Windows Vista → All
Product: Firefox → Core
Hardware: x86 → All
Oh, good catch. It might be useful to check further back to see if this is a regression.
Flags: firefox-backlog?
Trying to find a regression window, I checked 29.0.1 (20140506152807) and it's affected as well.
Setting the related flag.


Cheers,
Francesca
After further testing, I found that the bug is there since the first time the about:networking was introduced (with commit https://hg.mozilla.org/mozilla-central/rev/dcb7c39d1cf8) as 26.0a1 (20130808030205) is affected as well.

So to summarize: 

- 26.0a1 20130807161117 http://hg.mozilla.org/mozilla-central/rev/79b5c74ef97b is fine (merely because there is no about:networking feature here)

- 26.0a1 20130808030205 http://hg.mozilla.org/mozilla-central/rev/fd4cf30428b0 is broken (it's the first version where the about:networking feature was introduced), the commit introducing the feature was: https://hg.mozilla.org/mozilla-central/rev/dcb7c39d1cf8.

Silly question: can this be even qualified as regression, given that it's there since the first time the feature appeared? While still in doubt, I'm putting the "regression" keyword on the whiteboard, feel free to remove it, though. :)

Cheers,
Francesca
It's actually even older than that. The privacy issue exists since the implementation of nsIDashboard in 2012.

Currently working on a patch.
Assignee: nobody → valentin.gosu
Hi Patrick, I'm considering the following approach:

Listen for the browser:purge-session-history topic
Iterate through all the entries in nsHttpConnectionMgr::mCT
Remove those that have no active/idle connections

Does this sound ok?
Flags: needinfo?(mcmanus)
(In reply to Valentin Gosu [:valentin] from comment #6)
> Hi Patrick, I'm considering the following approach:
> 
> Listen for the browser:purge-session-history topic
> Iterate through all the entries in nsHttpConnectionMgr::mCT
> Remove those that have no active/idle connections
> 
> Does this sound ok?

I think that's fine.

I think you can also suppress the output of 0-live-socket entries from about:networking all the time.. they are kind of useful to have (cache some information about spdy e.g.) but they just clutter that display. wdyt?
Flags: needinfo?(mcmanus)
Comment on attachment 8440213 [details] [diff] [review]
clear about:networking hostname list when deleting history

The patch removes dead entries from the connection table.

Should we have a checkbox in about networking for the 0-live-socket entries? Or should we ignore them altogether?
Attachment #8440213 - Flags: review?(mcmanus)
Comment on attachment 8440213 [details] [diff] [review]
clear about:networking hostname list when deleting history

Review of attachment 8440213 [details] [diff] [review]:
-----------------------------------------------------------------

valentin - awesome. thanks!

::: netwerk/protocol/http/nsHttpHandler.cpp
@@ +1853,5 @@
>          nsCOMPtr<nsIURI> uri = do_QueryInterface(subject);
>          if (uri && mConnMgr)
>              mConnMgr->ReportFailedToProcess(uri);
>      }
>      else if (strcmp(topic, "last-pb-context-exited") == 0) {

let's _also_ do the clear connection history thing after last-pb-context-exited is observed. (you can abstract the runnable stuff without another review)
Attachment #8440213 - Flags: review?(mcmanus) → review+
(In reply to Valentin Gosu [:valentin] from comment #9)
> Comment on attachment 8440213 [details] [diff] [review]

> Should we have a checkbox in about networking for the 0-live-socket entries?
> Or should we ignore them altogether?

checkbox is better if you're up for the work.. default to dont show imo
Awesome. This seems worth nominating for uplift after it's fixed!
Try is all green. Pushing to inbound
https://tbpl.mozilla.org/?tree=Try&rev=43127f946375
https://hg.mozilla.org/mozilla-central/rev/83977d2750a2
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Hi Gavin, should this bug be approved for the backlog?  If yes, I'll add it to the current iteration.
Flags: needinfo?(gavin.sharp)
As a Core:Networking bug, we don't need to track this in our backlog.
Flags: needinfo?(gavin.sharp)
Flags: firefox-backlog? → firefox-backlog-
Comment on attachment 8440213 [details] [diff] [review]
clear about:networking hostname list when deleting history

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
 This bug has been in place since the original implementation of bug 783205
User impact if declined:
 The hostnames of websites visited in the current session will be visible in
 about:networking until shutdown (even after clearing history)
Testing completed (on m-c, etc.):
 Currently on mozilla-central
Risk to taking this patch (and alternatives if risky):
 Low risk. It touches few lines of the code.
String or IDL/UUID changes made by this patch:
 None
Attachment #8440213 - Flags: approval-mozilla-aurora?
Comment on attachment 8440213 [details] [diff] [review]
clear about:networking hostname list when deleting history

Aurora approval granted.
Attachment #8440213 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I verified this on FF Aurora 33 and FF 32.0b6 and I've noticed that in order for all of the hostnames to be cleared I require to tun Clear History several times. If I run it only once, like 25% of all hosts remain on about:networking, running again usually clears the issue.
Clearing the history doesn't delete the entries for pages that are still active/idle.
My test case was open 5 pages, close them all, wait a few seconds, clear history, check that those entries are no longer in about:networking.
Yeah I've done the same test but using like 10-15 tabs, closed them all waited like 20 sec and cleared history.
Could you please check the sockets tab to see that all of the sockets have been closed? There could also be half-open sockets, that are note displayed in that tab, which could also stop the entry from being cleared, but that should happen less often.
I've checked and it was due to sockets remaining open, but that brings me to the question why aren't sockets closing faster. For 15 tabs opened like 150 sockets are opened and closing them takes like 2 minutes. I've done the same test on Chrome and it takes like 3-5 seconds for sockets to be closed. Is this issue related to this bug or should I log a different one?
(In reply to Catalin Varga [QA][:VarCat] from comment #25)
> I've checked and it was due to sockets remaining open, but that brings me to
> the question why aren't sockets closing faster. For 15 tabs opened like 150
> sockets are opened and closing them takes like 2 minutes. I've done the same
> test on Chrome and it takes like 3-5 seconds for sockets to be closed. Is
> this issue related to this bug or should I log a different one?

That's not a bug - our sockets are shared between tabs and are closed based either on pressure on the pool (i.e. LRU), timers, or the server initiating the close. CDN connections in particular are pretty valuable to have around (there is much more overhead involved in establishing a socket than there is in maintaining it)
Verified the issue using the following environment:

FF32.0b7
Build id: 20140814150857
OS: Win 7 x64, Ubuntu 13.04 x64, Mac Os X 10.8.5
Verified as fixed using the following environment:

FF 33.0b1
Build Id: 20140902214533
OS: Win 7 x64, Ubuntu 13.04 x64, Mac Os X 10.8.5
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.