1153674 - Website are loading/connecting slow

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[lolbrol]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150411030207

Steps to reproduce:

 I visited hln.be and connecting takes ages. it happend when I updated to firefox 40
http://goo.gl/YXmfto This are people with the same problem. They are using firefox 37 and they say it also happens with a bunch of other websites like facebook etc. 


Actual results:

Slow loading

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It also happens on other browsers?

Comment 2

[lolbrol]

No problem with other browsers. Only with firefox. I reseted my Firefox preferences but the problem still occurred.

Comment 3

[Veldman]

Same here. I am on FF 37.01 on Windows 7 64bit.
www.hln.be doesn't open or opens after a long time (40 ... 120 seconds). While opening a message is displayed in statusbar: "waiting for staticX.hln.be" (X can be 1,2 or 3, but most of the time it is 2). During this time it is impossible to open other sites. If I exit, process stays busy in background.
Tried safe mode, resetting, copying profile, going back to previous version, but to no avail. Problem persists with and without adblock and ghostery enabled.
Same problem in Waterfox.
The site opens quick and without any problems in IE, Chrome and Palemoon on the same computer.

Comment 4

[StarWing]

Ditto :/

Same issue on 2 sepparate workstations.

If you have this issue, CPU usage is high on 1 core, and if you try to close FF, it stays open in the background for a while.
If FF hangs on this tab, you can open a new tab, but its "locked" until the hln.be tab loads.
enabling/disabling ublock/ghostery has no effect.

Comment 5

[Bogdan Maris, Desktop QA]

Can any of you try and see if this reproduces with clean profile? 

For me, the page loads fast enough using latest Nightly and clean profile on Windows 7 64-bit.

Comment 6

[Bogdan Maris, Desktop QA]

This is how to make a clean profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 7

[StarWing]

That doesn't seem to make much of a diffirence either.
When the page is eventually loaded, everything works smooth. You can close FF and reopen hln.be and it will load as expected. 
But if you wait like 10 minutes, it will probably hang.

Comment 8

[lolbrol]

A clean profile seems to resolve the problem in the latest nightly. A will try it a day an see if the problem stays away.

Comment 9

[Veldman]

For me (FF 37.01) a clean profile doesn't resolve the problem.

Comment 10

[Veldman]

I just installed Nightly (40.0a1 2015-04-17), both 32 and 64bit, and on both programs the site is loading normal, albeit slower than in IE. (Adblock+ and Ghostery are enabled.)
And just to be sure I tried 37.01 again and there the problem still persist. So it must be something in FF that is causing the problem?

Comment 11

[lolbrol]

The problem still happens, but I think it is a cookie problem.

Comment 12

[GJ]

Attachment: Compressed procmon csv logfile during the loading of hln.be

I have FF 37.01 on Windows 7.
I ran Sysinternals Process Monitor during the loading of hln.be and I attached filtered log file to this message.
During this test, the screen was white and it was waiting for some "static.hln.be" page.
When I look the log file, it looks like it's constantly parsing some anti-malware configuration files.
Task Manager said FF was running almost 25% CPU (on 4 cores laptop)

Also: after I close firefox by clicking on the x in the upper right corner, it is still visible in the Task Manager, running at 25%.

Comment 13

[lolbrol]

Also mobile version of firefox nightly is affected.

Comment 14

[Veldman]

When I disable "Block reported attack sites" and "Block reported web forgeries" in Options/Security, everything works normally. (Everything goes a lot faster on other sites to.)

Comment 15

[GJ]

Some more logging info.
I executed firefox with the following environment variables set:
  set NSPR_LOG_MODULES=all:5
  set NSPR_LOG_FILE=c:\firefox.log

The logging points to some endless loop around  Classifier::ApplyTableUpdates and Classifier::ApplyUpdates
These methods are found in mozilla-release\toolkit\components\url-classifier\Classifier.cpp and are executed recursively.

This piece of logging is repeatedly spawn:
4868[1980d920]: THRD(10dae740) ProcessNextEvent [0 0]
4868[1980d920]: THRD(10dae740) running [abdc1e0]
4868[1980d920]: nsUrlClassifierDBServiceWorker::CacheMisses [199ff6c0] 1
4868[1980d920]: THRD(10dae740) ProcessNextEvent [0 0]
4868[1980d920]: THRD(10dae740) running [abdc1f0]
4868[1980d920]: nsUrlClassifierDBServiceWorker::CacheCompletions [199ff6c0]
4868[1980d920]: CacheCompletion Addchunk 384948 hash A9BF84CB
4868[1980d920]: CacheCompletion Addchunk 383048 hash A9BF6808
4868[1980d920]: CacheCompletion Addchunk 386585 hash A9BF7973
4868[1980d920]: Completion received, but table is not active, so not caching.
4868[1980d920]: CacheCompletion Addchunk 380627 hash A9BF81EF
4868[1980d920]: Backup before update.
4868[1980d920]: Applying 4 table updates.
4868[1980d920]: Classifier::ApplyTableUpdates(goog-phish-shavar)
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 984795
4868[1980d920]: InflateReadTArray: 557 in 551564 out
4868[1980d920]: InflateReadTArray: 558 in 551564 out
4868[1980d920]: InflateReadTArray: 370656 in 551564 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: InflateReadTArray: 10 in 2 out
4868[1980d920]: Applied update to table goog-phish-shavar:
4868[1980d920]:   1 add chunks
4868[1980d920]:   0 add prefixes
4868[1980d920]:   1 add completions
4868[1980d920]:   0 sub chunks
4868[1980d920]:   0 sub prefixes
4868[1980d920]:   0 sub completions
4868[1980d920]:   0 add expirations
4868[1980d920]:   0 sub expirations
4868[1980d920]: Contains Completes, keeping cache.
13236[2612cd0]: Timer thread woke up 11.583045ms from when it was supposed to
13236[2612cd0]: [this=c732308] time between PostTimerEvent() and Fire(): 0.001642ms
13236[2612cd0]: [this=e1e6160] expected delay time 5000ms
13236[2612cd0]: [this=e1e6160] actual delay time   19690.380674ms
13236[2612cd0]: [this=e1e6160] (mType is 0)       -------
13236[2612cd0]: [this=e1e6160]     delta           14690ms
13236[2612cd0]: [this=e1e6160] Took 0.053369ms to fire timer callback
13236[2612cd0]: waiting for 21646
4868[1980d920]: Applied update to table goog-phish-shavar:
4868[1980d920]:   1 add chunks
4868[1980d920]:   0 add prefixes
4868[1980d920]:   1 add completions
4868[1980d920]:   0 sub chunks
4868[1980d920]:   0 sub prefixes
4868[1980d920]:   0 sub completions
4868[1980d920]:   0 add expirations
4868[1980d920]:   0 sub expirations
4868[1980d920]: Contains Completes, keeping cache.
4868[1980d920]: Applied update to table goog-phish-shavar:
4868[1980d920]:   1 add chunks
4868[1980d920]:   0 add prefixes
4868[1980d920]:   1 add completions
4868[1980d920]:   0 sub chunks
4868[1980d920]:   0 sub prefixes
4868[1980d920]:   0 sub completions
4868[1980d920]:   0 add expirations
4868[1980d920]:   0 sub expirations
4868[1980d920]: Contains Completes, keeping cache.
4868[1980d920]: Applied update to table goog-phish-shavar:
4868[1980d920]:   1 add chunks
4868[1980d920]:   0 add prefixes
4868[1980d920]:   1 add completions
4868[1980d920]:   0 sub chunks
4868[1980d920]:   0 sub prefixes
4868[1980d920]:   0 sub completions
4868[1980d920]:   0 add expirations
4868[1980d920]:   0 sub expirations
4868[1980d920]: Contains Completes, keeping cache.
4868[1980d920]: Applied 4 update(s) to goog-phish-shavar.
4868[1980d920]: Removed 0 dead SubPrefix entries.
4868[1980d920]: Table goog-phish-shavar now has:
4868[1980d920]:   9014 add chunks
4868[1980d920]:   551564 add prefixes
4868[1980d920]:   4 add completions
4868[1980d920]:   6267 sub chunks
4868[1980d920]:   2 sub prefixes
4868[1980d920]:   0 sub completions
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
... a lot of write() calls ...
4868[1980d920]: Saving PrefixSet successful
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 682814
4868[1980d920]: Active table: goog-badbinurl-shavar
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 12472
4868[1980d920]: Active table: goog-downloadwhite-digest256
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 789957
4868[1980d920]: Active table: goog-malware-shavar
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 984795
4868[1980d920]: Active table: goog-phish-shavar
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 232
4868[1980d920]: Active table: test-malware-simple
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/network/buffered-input-stream;1) succeeded
4868[1980d920]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/security/hash;1) succeeded
4868[1980d920]: read -> 232
4868[1980d920]: Active table: test-phish-simple
4868[1980d920]: Cleaning up backups.
4868[1980d920]: Done applying updates.
4868[1980d920]: update took 1763ms
... and then it starts all back again ...

Comment 16

[Frederick Sieber]

I noticed this just after installing 37.   For me it happens in about 15% of loads.  Load times go out to about a minute or more, but on other browsers they work fine.   I have tried safe mode, no effect.  Running on windows 8.1 64 bit Pro. I would like to try uninstalling plugins, but apparently there is no way to do that without completely reinstalling firefox.   In some cases disabling Flash helps, but not in all.

Comment 17

[Frederick Sieber]

Example:  http://www.economist.com/news/special-report/21648176-success-family-companies-turns-much-modern-business-teaching-its?fsrc=scn/tw/te/pe/ed/survivalofthefittest   This site took almost 5 minutes to load.  Status bar says .214 seconds to load, but it actually took almost 5 minutes.   WIndows explorer loaded in about .2 seconds.

Comment 18

[Frederick Sieber]

With this site:   http://www.economist.com/news/special-report/21648176-success-family-companies-turns-much-modern-business-teaching-its?fsrc=scn/tw/te/pe/ed/survivalofthefittest.   I used a little used laptop 8.1 windows, brought firefox up to the latest 37.  The site would load in about 26-30 seconds.  Chrome would load the site in 11-15 seconds.   Then I did a complete uninstall, wiping all associated firefox files, and reinstalled Firefox 37.  Now the site loads in about 19-20 seconds.   Perhaps on my more powerful desktop there would be a better improvement, implying the accumulated firefox gunk was slowing it down for these users who are now complaining.   When I get the courage to do it on my desktop, will report back.

Comment 19

[Frederick Sieber]

Update, lastest activity:   Seen for the last few months. 
		Tried safe mode, did not work.
		Tried complete reinstall, inhibit old plugins, did not work
		Tried earlier versions 3.5.3.6,3.7  mixed results
		Tried firefox tweak add on,  may have improved somewhat
		GOes for a while OK, then it hits,   restarting firefox does not help. 
		Rebooting solves it, for a while. 
		Suspect resource exhaustion. 
		User just sees spinning indicator, may go on for some time, even though it seems the page is all there. 
		When gets bad, keeps on being bad,  may be somewhat gradual
		Suspect graphics resource shortage, because high graphics page make it worse.
		Connection to  flash still unclear.

Comment 20

[lolbrol]

I have no problems to open the website you link to.. Veldman shared a temporary solution.

"When I disable "Block reported attack sites" and "Block reported web forgeries" in Options/Security, everything works normally. "

Comment 21

[Frederick Sieber]

Disabing "Block reported attack sites" and "Block reported web forgeries" in Options/Security, did not seem to help my problem.   I work for a while, then am forced to reboot, as described previously.   In one case only, after I rebooted, still had delays.   In one case, delays started after enabling flash.  But the last two were isolated cases.   Mostly just working for a while, then rebooting, or switching to chrome, which has no problems at all.

Comment 22

[Frederick Sieber]

And flash.  This is related to the flash/firefox slowdown.   I have had a case where I enabled flash, and immediately I could not load any pages.  I have had a case where flash was enabled,  I could not load a page, I disabled flash, then I could load the pages, and go longer.   The general behavior is, after a while of usage, things begin to slow, then they slow to infinity, then you have to reboot.   Apparently using flash makes the situation worse,  you can go a lot longer with flash disabled.  Still looks like a leak of some graphic resource.

Comment 23

[Brindusa Tot, Desktop QA]

Could not reproduce this on Windows 7 x64, with Released Firefox 43.0.1 (buildID:20151216175450, user agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0_ and Nightly 46.0a1 (buildID: 20151221114259, user agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0)

Tried with "Block reported attack sites" and "Block reported web forgeries" enabled and disabled, and also with flash activated and disabled and could not reproduce the bug.

Frederick Sieber, can you please confirm whether this issue still occurs using latest Firefox version?

Comment 24

[Frederick Sieber]

I am currently running 43.0.2 on Windows 10 64 bit.   This problem has not been noticeable recently although I am still avoiding using flash on ancestry.com, but don't know if that is necessary.   At the time it seemed useful to avoid using flash on ancestry.com and findagrave.com.    I think I did experience it (slow loading) on one site, but it is now a more rare occurrence.

Comment 25

[Brindusa Tot, Desktop QA]

For the time being, as the bug is not reproducible now, mark the bug Resolved Worksforme. 

@reporter/@commenter: if the issue will occur in the future, please do not hesitate to reopen the issue while providing additional details that could help us reproduce.