Firefox tries to connect to webpages I'm not on anymore.
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: ftpd+sites, Unassigned)
Details
Attachments
(1 file)
1.23 MB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
- go to example.com;
- allow the connection in firewall (Little Snitch for mac);
- go elsewhere (by: entering new page address / closing the tab / closing the entire browser);
- delete rule allowing connection in firewall;
- wait (minutes to even hours/next day).
Actual results:
Little Snitch will popup the window asking if I want to allow connection from Firefox to example.com.
Expected results:
Nothing - I'm not on example.com anymore, I don't want my browser connecting to it without my knowledge.
I've tried:
- disable service workers;
- add boolean browser.pagethumbnails.capturing_disabled preference set to true.
No changes - it still tries to connect.
Reporter | ||
Comment 1•4 years ago
|
||
Attached screenshot is the prrof: I went to cnn.com, switched to google.com, and after few minutes my Firefox tried to open connection back to cnn. No outgoing http requests in Network Monitor, though.
Comment 2•4 years ago
|
||
Hi,
Can you please confirm if you uses little snitch 4.5.2 so I can try to replicate on my end?
I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.
Thanks for the report.
Best regards, Clara.
Comment 3•4 years ago
|
||
This is probably not related to webrtc, let's move this to the networking component.
Comment 5•4 years ago
|
||
(In reply to Bartek Stalewski from comment #1)
Attached screenshot is the prrof: I went to cnn.com, switched to google.com, and after few minutes my Firefox tried to open connection back to cnn. No outgoing http requests in Network Monitor, though.
I cannot reproduce it on Linux. After switching to google.com the connections to cnn servers are kept alive (but no request is made) for a while and then they are closed. The request wouldn't belong to the current window, so it couldn't be visible in Network Monitor, but it would be in HTTP log. Could you please provide log which would show the problem?
Reporter | ||
Comment 6•4 years ago
|
||
Sure, here it is: https://insomniac.pl/mozilla_bug.log (it was too big to attach it here).
The workflow was:
- manual connection to cnn.com
- manual connection to duckduckgo.com
- wait
- connection request to MozillaZine (I've allowed it)
- connection request to CNN (declined).
Please notice connections to 'mozillazine.com' - it's another example of connection to something I was browsing a long time ago (previous week, I was not using Firefox between 4 days ago and today), also it helps to determine which connections to CNN are made by me manually (on the beginning of a file) and which are generated
Comment 7•4 years ago
|
||
(In reply to Bartek Stalewski from comment #6)
Sure, here it is: https://insomniac.pl/mozilla_bug.log (it was too big to attach it here).
Authentication is required to download the log.
Reporter | ||
Comment 8•4 years ago
|
||
Oh, silly me, wrong address:
https://insomniac.pl/f/mozilla_bug.log
Comment 9•4 years ago
|
||
(In reply to Bartek Stalewski from comment #6)
- connection request to MozillaZine (I've allowed it)
- connection request to CNN (declined).
I don't see any request to cnn.com after the request to MozillaZine in the log. Request "http://kb.mozillazine.org/About:config_entries#Browser." has the same topwinid as ghostery related requests, so I guess the requests are generated by this addon. Try to disable it to see if they dismiss.
Reporter | ||
Comment 10•4 years ago
|
||
2020-06-15 13:18:00.485031 UTC - [Parent 29245: Main Thread]: V/nsHttp HttpChannelParent RecvAsyncOpen [this=0x11ca57550 uri=http://kb.mozillazine.org/About:config _entries#Browser., gid=125619203473438 topwinid=12]
2020-06-15 13:18:37.445374 UTC - [Parent 29245: Socket Thread]: V/nsHttp nsHttpConnectionMgr::ProcessPendingQForEntry [ci=.S......[tlsflags0x00000000] www.cnn.com:4 43 ent=0x11d590200 active=1 idle=0 urgent-start-queue=0 queued=0]
So 37 seconds later.
I've tried on a fresh profile, so without any addons. I've tested everything that I was able to think of before creating this bug, googled a lot and tried to solve it on reddit and 'official Mozilla chat'. I'm sysadmin IRL, so please trust me, that I don't throw bugs like that away and blaming everyone around when my software doesn't work, I always try to find the solution myself ;-)
I will try to create a screen recording of this bug to prove it somehow.
Reporter | ||
Comment 11•4 years ago
|
||
Ok, here it is: https://insomniac.pl/f/mozilla_bug.mp4
Also, I've created second log file, with only the session from screen recording: https://insomniac .pl/f/mozilla_bug_2.log.
The legit and desired connection to cnn.com is at 22:05:36 timestamp in the log file (12:05:36 on my system clock in the 'movie', as I'm UTC+2), the unwanted one at 22:05:41 (failed, as I've denied it).
Reporter | ||
Comment 12•4 years ago
|
||
https://insomniac.pl/f/mozilla_bug_2.log - sorry, I can't edit previous comment, here is clickable link.
Reporter | ||
Comment 13•4 years ago
|
||
(In reply to Bartek Stalewski from comment #11)
The legit and desired connection to cnn.com is at 22:05:36 timestamp in the log file (12:05:36 on my system clock in the 'movie', as I'm UTC+2), the unwanted one at 22:05:41 (failed, as I've denied it).
22:06:41, my mistake, sorry.
Comment 14•4 years ago
|
||
(In reply to Bartek Stalewski from comment #13)
(In reply to Bartek Stalewski from comment #11)
The legit and desired connection to cnn.com is at 22:05:36 timestamp in the log file (12:05:36 on my system clock in the 'movie', as I'm UTC+2), the unwanted one at 22:05:41 (failed, as I've denied it).
22:06:41, my mistake, sorry.
Thanks for the video and the log. They are really helpful.
I think what you see at 22:06:41 is a HTTP2 ping frame.
2020-06-15 22:06:41.310455 UTC - [Parent 39687: Socket Thread]: I/nsHttp Http2Session::ReadTimeoutTick 0x12bd5b800 delta since last read 58s
2020-06-15 22:06:41.310470 UTC - [Parent 39687: Socket Thread]: I/nsHttp Http2Session::ReadTimeoutTick 0x12bd5b800 generating ping
2020-06-15 22:06:41.310488 UTC - [Parent 39687: Socket Thread]: I/nsHttp Http2Session::GeneratePing 0x12bd5b800 isAck=0
2020-06-15 22:06:41.310505 UTC - [Parent 39687: Socket Thread]: V/nsHttp Http2Session::LogIO 0x12bd5b800 stream=0x0 id=0x0 [Generate Ping]
2020-06-15 22:06:41.310526 UTC - [Parent 39687: Socket Thread]: V/nsHttp 00000000: 00 00 08 06 00 00 00 00 00 00 00 00 00 00 00 00
2020-06-15 22:06:41.310543 UTC - [Parent 39687: Socket Thread]: V/nsHttp 00000010: 00
2020-06-15 22:06:41.310559 UTC - [Parent 39687: Socket Thread]: V/nsHttp nsHttpConnection::OnReadSegment [this=0x12c07e000]
2020-06-15 22:06:41.310576 UTC - [Parent 39687: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::Write [this=0x12c0326c8 count=17]
2020-06-15 22:06:41.310592 UTC - [Parent 39687: Socket Thread]: D/nsSocketTransport calling PR_Write [count=17]
Let me quote what spec said about PING.
I think this is expected behavior, so close this as WONTFIX.
In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection. Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request.
Reporter | ||
Comment 15•4 years ago
|
||
Ok, thanks, I'm fine with that.
I just wonder how other browsers don't to that. Is the HTTP2 Ping common thing or it's just added in Firefox (because of reasons)?
Description
•