1020539 - about:networking hostname list not clearing after deleting history

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Landpaddle]

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.

Comment 1

[Francesca Ciceri [:madamezou]]

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

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Oh, good catch. It might be useful to check further back to see if this is a regression.

Comment 3

[Francesca Ciceri [:madamezou]]

Trying to find a regression window, I checked 29.0.1 (20140506152807) and it's affected as well.
Setting the related flag.


Cheers,
Francesca

Comment 4

[Francesca Ciceri [:madamezou]]

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

Comment 5

[Valentin Gosu [:valentin] (he/him)]

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

Currently working on a patch.

Comment 6

[Valentin Gosu [:valentin] (he/him)]

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?

Comment 7

[Patrick McManus [: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?

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Attachment: clear about:networking hostname list when deleting history

Comment 9

[Valentin Gosu [:valentin] (he/him)]

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?

Comment 10

[Patrick McManus [: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)

Comment 11

[Patrick McManus [:mcmanus]]

(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

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Awesome. This seems worth nominating for uplift after it's fixed!

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Try is all green. Pushing to inbound
https://tbpl.mozilla.org/?tree=Try&rev=43127f946375

Comment 14

[Valentin Gosu [:valentin] (he/him)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/83977d2750a2

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/83977d2750a2

Comment 16

[Marco Mucci [:MarcoM]]

Hi Gavin, should this bug be approved for the backlog?  If yes, I'll add it to the current iteration.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

As a Core:Networking bug, we don't need to track this in our backlog.

Comment 18

[Valentin Gosu [:valentin] (he/him)]

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

Comment 19

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8440213 [details] [diff] [review]
clear about:networking hostname list when deleting history

Aurora approval granted.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b124230d0fa9

Comment 21

[Catalin Varga [QA][:VarCat]]

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.

Comment 22

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 23

[Catalin Varga [QA][:VarCat]]

Yeah I've done the same test but using like 10-15 tabs, closed them all waited like 20 sec and cleared history.

Comment 24

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 25

[Catalin Varga [QA][:VarCat]]

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?

Comment 26

[Patrick McManus [:mcmanus]]

(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)

Comment 27

[Catalin Varga [QA][:VarCat]]

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

Comment 28

[Catalin Varga [QA][:VarCat]]

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