I experienced severe jank (30+s) in nsProtocolProxyService when an open tab was on a Jenkins web site. The attached patch is the output from the SPS profiler on official builds of Nightly 2012-08-09 on Windows 7. All the jank appears to be inside core win32 dlls. The last Firefox API is ReadInternetOption(). This is called by nsWindowSystemProxyService::getPACURI, which is called by nsProtocolProxyService::resolve*. It all chains up to an nsXMLHttpRequest::Open. My computer (Core i7 2600K) was under heavy load at the time this happened. But, the rest of my Windows UI was responsive while Firefox was non-responsive. When I have the Jenkins tab open, jank occurs with regular frequency (I'm pretty sure it is related to a repeating timer on the web site). I'm not sure if the HTML is doing something really dumb (tm). But, I would expect it to not cause jank if waiting on a system call that could take 30+s. The computer I'm experiencing this on was recently moved to a new network. I suspect this plus FoxyProxy might be causing some weirdness.
s/nsWindowsSystemProxyService/nsWindowsSystemProxySettings/. Lack of copy + paste in the profiler UI plus a few beers is not a good combination.
I have FoxyProxy installed, but I have it disabled through the FoxyProxy UI ("Completely disable FoxyProxy" option).
This profile shows the same jank behavior and similar call stack. The only difference is it chains up to hitting the back button in the browser, not some XMLHttpRequest from content.
Thanks :gps - Josh is right that 769764 has grown from its original scope of just DNS jank to also include the jank you report here. Its a tricky thing to solve. 769764 will resolve it for all cases except plugins, which are covered in 778201. I'm actually not sure what this means for FoxyProxy - I'll have to add that to my todo list to look into.
Roc and I were seeing something similar in an earlier bug, but that was supposed to be fixed.
(In reply to Kyle Huey [:khuey] (email@example.com) from comment #6) > Roc and I were seeing something similar in an earlier bug, but that was > supposed to be fixed. you are probably thinking of 235853.. the patch for that bug *] didn't try and fix the whole problem *] didn't actually fix any of the parts it did try to solve *] caused other regressions it was backed out :)
No, I was thinking of bug 774242.
FWIW, I worked around this by changing my default network settings from "Use system proxy settings" to "No proxy."
Is this still a problem? Seems like it should be resolved, so marking this as fixed, reopen if I'm wrong.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
The problem seems to have gone away with all the async proxy rewrite stuff from a few months back.
I'm seeing quite a few of these stacks in Telemetry chrome-hang data from Nightly 22. Is there another bug for this? InternetGetConnectedStateExW (in wininet.pdb) ReadInternetOption (in xul.pdb) nsWindowsSystemProxySettings::GetPACURI(nsACString_internal &) (in xul.pdb) nsProtocolProxyService::PrefsChanged(nsIPrefBranch *,char const *) (in xul.pdb) nsProtocolProxyService::Init() (in xul.pdb) nsProtocolProxyServiceConstructor (in xul.pdb) mozilla::GenericFactory::CreateInstance (in xul.pdb) nsComponentManagerImpl::CreateInstanceByContractID (in xul.pdb) nsComponentManagerImpl::GetServiceByContractID (in xul.pdb) nsCOMPtr_base::assign_from_gs_contractid_with_error(in xul.pdb) mozilla::net::nsHttpChannel::ResolveProxy() (in xul.pdb) mozilla::net::nsHttpChannel::AsyncOpen (in xul.pdb) nsURILoader::OpenURI (in xul.pdb) nsDocShell::DoChannelLoad(nsIChannel *,nsIURILoader *,bool) (in xul.pdb) nsDocShell::DoURILoad(nsIURI *,nsIURI *,bool,nsISupports *,char const *,nsAString_internal const &,nsIInputStream *,nsIInputStream *,bool,nsIDocShell * *,nsIRequest * *,bool,bool,bool) (in xul.pdb)
vladan - that is 846914
You need to log in before you can comment on or make changes to this bug.