Firefox network monitor is behaving in a way I do not understand. Sometimes, when I select a network request in the dev tools, it selects multiple (seemingly random) other requests as well. Details from only one of the requests are shown on the details pane (again, seemingly random as to which request's details). It also seems to "forget" to display the return status codes, even though the requests DO complete.
Screenshot (I've only selected 1 network request)
It's been doing this for weeks, and now it's critically impacting my ability to move forward on a Vue project I'm working on. Multiple Google searches have turned up nothing. Have I found a bug in FF, or is this expected behavior that I'm misinterpreting?
Ubuntu 20.04
Firefox 79.0 (also occurred in previous versions)
Related
When debugging using the chrome's performance profiler i recorded a reload of my own page. The following is the result.
chrome performance profiler screenshot
After reloading the page, there is a 25 second network request that first happens, then the website loads really ast. I've been searching the internet for an answer on how to debug this further or why this could happen but honestly I can't figure it out.
I've tried using another network, my 4G on mobile, flushing DNS, using other browsers/incognito, clearing cache. Nothing works.
My hosting company says that this is a problem on my end and GTmetrix also show very good results. But I'm not sure i trust it since it happens on both my phone and computer. (4G roaming on phone)
I have a problem with live video streams in the system I am developing that happens only in Firefox and only in normal mode.
The player correctly loads the stream, but after a few seconds can't continue to load and just keeps trying and trying forever.
This doesn't happen in Chrome, nor if I load the page in Private Mode, nor with normal videos. Just with live streams, just in Firefox, just in normal mode.
This happens both in local development (home, remote connection) and in the corporative cloud.
It's an Angular 8/NodeJs system and the player I use is Clappr. I changed to Video.js and the problem continued.
The stream is coming from a load balancer with 6 children servers, each one with an apache server who have a proxy to an icecast server that originates the stream.
[load balancer] < [6 child servers with apache server proxy] > [icecast server]
I work for a very large company that has an IPS system installed. It was the first thing I thought. But the IPS team could not find any blocked traffic. Also if it was that, why would the traffic not be blocked in private mode?
So I thought about trying to pinpoint what the exact configuration is different in private mode that does the trick and I figured out that disabling all history (not only navigation and downloads or forms) makes it work too.
Does anyone knows what exactly happens when the navigation history is disabled? Besides not saving history, does it have an impact on something else? Some type of cache, network or something like that? Anyone has any idea about how to make stream work without disabling history? I can't ask my users to disable history just to use my system.
EDIT
One thing that may be relevant to the issue is that in Firefox it doesn't show LIVE label when the transmission starts. It shows a negative number. Maybe this could create some problem with the history.
I couldn't find the information on what exactly happens when we disable history in Firefox, but I could solve the problem of playing the stream in Firefox, so I won't accept this answer, but leave it here for future reference in case someone has a similar problem.
I solved it by adding ?nocache=<random integer of length 10> to the video url. Please notice that if you already have some parameter in your url, you can't have 2 ? characters in your url and have to mix parameters correctly.
I have been having issues with loading pages from the website I created. The strange thing is that after I reload a page (e.g. Ctrl+R) especially if I do it multiple times in a row, sometimes that page loads flawlessly fast, sometimes it takes 10-20 seconds and sometimes it doesn't load at all, because, based on the Network tab in the Developer panel, some files are 'pending' to load, but never load. I'm then getting a "proxy could not connect to the destination in time" error if the very first index.php doesn't load, or the page loads only partially and I'm getting an error in the Console "could not connect to [filename]'
Few facts to keep in mind:
This issue occurs on all browsers I tested (Chrome, Firefox, IE, and Opera)
I am not focused on asynchronizing the stylesheets or script files at this point. As a result, my pages are not loaded until all files are loaded, but at this stage of development, this is not a top priority
I'm using GoDaddy shared hosting for this website
I am accessing the website through a corporate proxy server (I believe they use McAffee Enterprise)
If I test the loading speed using external tools (tools.pingdom.com or google developers tool), there appears to be no issue with the loading speed
Even under the corporate proxy server, I have never had this issue with any other websites
My questions is whether anybody else had this issue and knows how to mitigate it. If it's the proxy, I'm not sure why other sites work just fine. Any thoughts?
Sometimes, perhaps once every few hundred AJAX requests and/or where AJAX requests are executing in quick succession, I've seen a request hang for up to several minutes before it completes. The weird thing is that the request completes successfully AND neither my machine or the server are really doing anything either (e.g. CPU and other resources are not spiking during the "hang").
I've noticed this issue with various web services too, so it isn't just my own website. It also isn't database related as it has happened on non-database sites. It also only seems to show up in non-localhost environments.
When I personally use AJAX, I am also using jQuery, so this might also be a jQuery issue. I also mostly use Firefox, so I don't know if this is just a Firefox issue or if it is an issue any browser could have. I've run into the issue on multiple computers in multiple locations.
If you have run into this issue before and "fixed" it, I would appreciate the solution you came up with.
Use a HTTP debugger like Firebug or Fiddler to track the AJAX requests to see how much time it takes (possible timeout issue due to server setting?) & what HTTP response status code it returns when it fails. Use the HTTP response status code to troubleshoot the issue.
I'm using Firebug 1.5.2 and while testing a site before production release i can see a huge amount of time consumed by 'Blocking' parts of the requests.
What exactly does the 'Blocking' mean?
"Blocking" previously (earlier versions of FireBug) was called "Queuing". It actually means that request is sitting in queue waiting for available connection. As far as I know number of persistent connections by default is limited in last versions of Firefox to 6, IE8 also 6. Earlier it was only 2. It can be changed by user in browser settings.
Also as I know that while javascript file is loading, all other resources (css, images) are blocked
Blocking is a term used to describe an event that stops other events or code from processing (within the same thread).
For example if you use "blocking" sockets then code after the socket request has been made will not be processed until the request is complete (within the same thread).
Asynchronous activities (non blocking) would simply make the request and let other code run whilst the request happened in the background.
In your situation it basically means that certain parts of firebug / the browser cannot activate until other parts are complete. I.e. it is waiting for an image to download before downloading more.
As far as I know, two reasons cause components to cause blocking others from loading.
Browser's enforced (but usually configurable) limit of how many parallel resources can be loaded from a particular host at a time.
Inline javascript, which can cause the browser to wait and see if it at all needs to go ahead with downloading the rest of the components (just in case the javascript redirects or replaces the content of the page)
It means "waiting for connection". As explained in the official documentation by Mozilla, "Blocking" is "Time spent in a queue waiting for a network connection." That can be due to Firefox hitting its internal parallel connections limit, as explained there and in answers here.
It can also mean "waiting because server is busy". One possible reason for "Blocking" times is missing in the official documentation linked above: it can happen when the server cannot provide a connection at the time because it is overloaded. In that case, the connection request goes into a queue on the server until it can be processed once a worker process becomes free [source].
In a technical sense, such a connection is not yet established because the request is awaiting accept() from the server [source]. And maybe that is why it is subsumed under "Blocking" by Firefox, as it could also be considered "Time spent in a queue waiting for a network connection".
(This behaviour is not fully consistent as of Firefox 51 though: for the first URL called up in a new tab, the time before the server accepts the connection request is not counted at all in the "Timings" tab – only for subsequent URLs entered. Either of both behaviours could be a bug, I don't know which one.)