Pages (e.g. Facebook, Upwork) stop dynamically loading new content after a while
Categories
(Core :: Networking, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox95 | --- | affected |
People
(Reporter: shahtufail117, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Loading facebook and upwork and other web based services and stops loading content after a few 10 or 15 of them.
Actual results:
Facebook content stops loading and says to refresh, and sometimes upwork also stops loading content after a while.
Expected results:
the content should be loading one after the other in an infinite scroll
| Reporter | ||
Comment 1•4 years ago
|
||
It starts to work again only after i clear cache and refresh, all in all i have to do this after every two or so hours.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•4 years ago
|
||
Not sure what the best component for this is, but Networking might be a good start.
Comment 4•4 years ago
|
||
Eden, can this be related to service workers? I do not really see that this can be necko issue.
Comment 5•4 years ago
|
||
Not sure if it is related to a service worker issue or not.
Need more information for debugging. Unfortunately, I could not reproduce it in my local.
According to comment 1, it is probably a regression of bug 1722502. However, it needs to be confirmed.
Just a guess from a high-level view that if quota mitigation fails, it is possible to meet the case.
I will take a look to see if there is a case that makes the quota mitigation fails.
Comment 6•4 years ago
|
||
Since this seems difficult to reproduce, could you assist us with using mozregression to figure out when the bug started happening: https://mozilla.github.io/mozregression/quickstart.html
This should confirm if comment 5 is correct.
Comment 7•4 years ago
|
||
I meet the loading stop once with nightly 94, but it is not the issue I mentioned in comment 5.
Important Update.
I found a way to reliably replicate the bug.
It's also happening at certain other sites. For example, you can cause the malfunction by doing the following:
- Go to https://www.lifeextension.com
- In the search box at the top, type something and hit the Enter key.
Result: Firefox malfunction - search results page never loads.
I have tested this on 3 different PCs and also in troubleshooting mode.
The page works fine in Chrome!
Comment 9•4 years ago
|
||
(In reply to Intrepid from comment #8)
Important Update.
I found a way to reliably replicate the bug.
It's also happening at certain other sites. For example, you can cause the malfunction by doing the following:
- Go to https://www.lifeextension.com
- In the search box at the top, type something and hit the Enter key.
Result: Firefox malfunction - search results page never loads.I have tested this on 3 different PCs and also in troubleshooting mode.
The page works fine in Chrome!
Not sure why I can't reproduce this locally.
Could you try to capture a http log?
Thanks.
Comment 10•4 years ago
|
||
The issue happens sporadically. I've captured a log for https://www.lifeextension.com when using the product search on the page.
Comment 11•4 years ago
|
||
(In reply to Intrepid from comment #10)
Created attachment 9247648 [details]
log.txt-main.14648.moz_log.zipThe issue happens sporadically. I've captured a log for https://www.lifeextension.com when using the product search on the page.
Thanks for the log.
It shows that the connection to www.lifeextension.com is closed by the server, since we read 0 byte from the socket.
However, it's unclear why the server closes the connection.
It's probably worth to mention that the issue related to www.lifeextension.com may not the same as facebook, since we connect to www.lifeextension.com via http/2 and facebook is via http/3.
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: D/nsSocketTransport nsSocketInputStream::Read [this=28e1cd3e678 count=9]
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: D/nsSocketTransport calling PR_Read [count=9]
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: D/nsSocketTransport PR_Read returned [n=0]
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: I/nsHttp Http2Session 28e0f53b800 buffering frame header read failure 80470002
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: V/nsHttp nsHttpConnection::OnSocketReadable 28e1cd45000 trans->ws rv=80470002 n=0 socketin=80470002
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: V/nsHttp nsHttpConnection::CloseTransaction[this=28e1cd45000 trans=28e0f53b800 reason=80470002]
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: V/nsHttp nsHttpConnection::DontReuse 28e1cd45000 spdysession=28e0f53b800
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: I/nsHttp Http2Session::DontReuse 28e0f53b800
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: V/nsHttp closing associated mTransaction
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: I/nsHttp Http2Session::Close 28e0f53b800 0
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: I/nsHttp Http2Session::CloseStream 28e0f53b800 28e11c56380 0x15 80004004
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: I/nsHttp MaybeDecrementConcurrent 28e0f53b800 id=0x15 concurrent=1 active=1
2021-10-25 22:15:16.302000 UTC - [Parent 14648: Socket Thread]: V/nsHttp nsHttpTransaction::Close [this=28e0af8c000 reason=80004004]
Comment 12•4 years ago
|
||
Facebook: Waiting for static.xx.fbcdn.net
Comment 13•4 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #11)
I Attached a log for facebook. Thanks.
Comment 14•3 years ago
|
||
Can't say if it's useful but, I have this unwanted behaviour since FB's DNS change (messup) event
Comment 15•3 years ago
|
||
Here is the main bug page: https://bugzilla.mozilla.org/show_bug.cgi?id=1735595
Comment 16•3 years ago
|
||
We'll try to fix this in bug 1752270.
Description
•