If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Website are loading/connecting slow

RESOLVED WORKSFORME

Status

()

Firefox
Untriaged
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: lolbrol, Unassigned)

Tracking

40 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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
It also happens on other browsers?
Flags: needinfo?(zoelskoeltem03_05_)
(Reporter)

Comment 2

3 years ago
No problem with other browsers. Only with firefox. I reseted my Firefox preferences but the problem still occurred.
Flags: needinfo?(zoelskoeltem03_05_)

Comment 3

3 years ago
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

3 years ago
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.
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.
Flags: needinfo?(zoelskoeltem03_05_)
Flags: needinfo?(veldmansberg)
Flags: needinfo?(firefox)
This is how to make a clean profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 7

3 years ago
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.
Flags: needinfo?(firefox)
(Reporter)

Comment 8

3 years ago
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.
Flags: needinfo?(zoelskoeltem03_05_)

Comment 9

3 years ago
For me (FF 37.01) a clean profile doesn't resolve the problem.
Flags: needinfo?(veldmansberg)

Comment 10

3 years ago
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?
(Reporter)

Comment 11

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

Comment 12

3 years ago
Created attachment 8595459 [details]
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%.
(Reporter)

Comment 13

2 years ago
Also mobile version of firefox nightly is affected.

Comment 14

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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.
(Reporter)

Comment 20

2 years ago
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

2 years ago
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

2 years ago
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.
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?
Flags: needinfo?(sieber)

Comment 24

2 years ago
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.
Flags: needinfo?(sieber)
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.