Browser lagging out
|
|
Hi again Yah, I should probably have mentioned this sooner, but there are days when this script kills my browser ...not a crash, just an inability to move past the pages that are loaded, doesn't matter whether in single or multiple tabs. So if I click on anything (eg a link, or a submit button), nothing happens. The only way for me to sort this out when it happens is to turn off Greasemonkey (just to be clear, yours is the only script I'm running) and then restart the browser. When I first got the script I couldn't really use it for a couple of weeks. I updated the browser, uninstalled and reinstalled everything, tried a whole bunch of things to no avail. Then a few days after I'd given up, it started working. I persevere with this problem because I love the script, but I figured since nobody else has notified you of the problem, I should do so. My suspicion is that this occurs when MU links aren't able to be checked properly. I could be wrong about this though. cheers, and thanks for all your great work so far, CP |
|
|
CP, This is good info. I have seen this happen once or twice myself. During normal browsing with the script turned on, I almost never have an issue. However, doing a Link Check, I have seen the script wander off into never-never land. It starts eating memory at an accelerated rate.
|
|
|
LOL I know this isn't quite right to say, but I am glad to know it's just not me! ;) Since nobody else had reported it I had definitely wondered about that. Okay, I will document as much as possible. First, to give you some basics: - I am using Firefox 3.0.6 - Windows XP Pro 2002 SP 3 - Pentium 4 CPU 3Ghz / 1GB RAM - Internet is running over cable network, download speed 2Mbps / upload 256kbps
My experience so far... - I tend to have multiple tabs open most of the time - usually anything from two to six tabs. The problem can occur when I am only using one though. - I have found that the problem is more likely to occur when the page has a large number of links to check. - It is also more likely to occur when it is peak time for my ISP. At these times I tend to turn off the script. So bandwidth might be an issue. - If I have multiple tabs open with long lists of links the problem is almost certain to occur. - I have noticed that when it does occur, the Megaupload links tend not to have any results reported yet (thus my suspicion). - The browser doesn't have to have been open for long - if it's a bad day then it could occur on the first page I open in the first tab. So these are some general thoughts from memory. Next time it happens I will try to document some more specific information. I'll look at memory and CPU usage at the time too; this is not something I'd thought to check on. It would be terrific if we could sort this one out, because like you, I prefer to have the script running all of the time. I'm not sure how to do that separate iteration of the browser, although it sounds useful for testing purposes. Would you like me to try it? If so, I would need some instructions. cheers, and thanks for looking into this Yah. CP |
|
|
CP, I have two 100% guaranteed ways to work around this for you. One Bad, one Good.
|
|
|
Eep. I just went to Megaupload settings and actually, direct downloads were already deactivated... not really keen on removing the cookie, as I use it for filefetching, logging in automatically etc. It's kind of convenient having it. Any other suggestions? |
|
|
CP, Do you have any other FF Add-Ons installed? Another possibility is Download Accelerators like "Internet Download Manager" that integrates itself into FF and installs it's own Add-On into the browser. These might be affecting the way the script is functioning for you. Let me know,
|
|
|
Add-ons in my FF are minimal, as follows:
Hopefully over the next few days I will be able to do a bit of proper testing and keep some notes for you. This past few days I had a lot to get done so I couldn't turn on the script and risk any slow down. |
|
|
CP, I uploaded the test version of the 2.0 script as a new script here:
It give you the ability to disable checking of each individual host site. You can disable just Megaupload if you want. It adds a TCLC Prefs button at the bottom of each page that opens up a preferences window. If you'd like to try this, uninstall the current script and install this one. This is a safer way for me to install/maintain test versions of the script. Hope it can help you,
|
|
|
I checked your test version, yay, and since I saw the commented upcoming Preferences stuff, I wanted to ask if you intend to allow us to display the Prefs window thru User Script Command as AIO does it or keep it the way it's now (adding element to page, which is horrible btw :))? |
|
|
Lukáš, For testing purposes, I left the prefs button on the page. For now, that's where it'll stay. It's a lot quicker than navigating through the menu 100 times an hour during testing. There are several different ways to accomplish a professional looking menu. I won't say AIO's choice is the best but it is an option. yah. |
|
|
Hi Yah, Well this makes a world of a difference and is very much appreciated. Turning off MU has fixed everything. I discovered over the past few days (via a great deal of determined digging), that there was a pretty major problem going on. For a while I thought I had a virus, but now that I've used the test script and disabled access to MU, I realise it was the script causing the issues. You may want to consider blocking MU until it is resolved, because this is pretty serious stuff. As it turns out, when I checked in with various other users of TCLC on forums I am a part of, they are experiencing similar problems but have had no idea what was going on. Basically, the script was opening up connections to several different hosts on MU, all beginning with one of three IP prefixes: 209.222.128.xxx / 174.140.128.xxx / 66.117.43.xxx (it took me a while to narrow these down to MU but eventually I got there). Once these connections were opened, very large downloads of unknown data were coming through to an unknown location on my machine. These downloads wouldn't stop until I killed the browser, which would break the connections within a minute or two. Once my bandwidth was upgraded, these downloads simply got faster. I spied on my connection and kept notes over a few days to narrow all of this down. Here's an example of what I was experiencing: --- Connections:
All downloading at about 85Kbps each total download: over 1.1GB downloaded (from 7:16am to 7:56am Mon 2 Mar (40 mins)) --- Now that I have switched off access to MU using your preferences button, the script is behaving properly and the weird downloads are not occurring anymore. My browser is happy and the world has become a sunny place. :D You have no idea how relieved I am. Until I was able to turn MU off in the test script, I was beginning to think I had a new virus (Norton/AVG and several other scanners refused to find anything) and that I would need to rebuild my machine all over again to clear it up. I had also been forced to browse using IE, which I have to say was simply heartbreaking. ;) For now, I will just use the test script with MU switched off. If you want me to do any further testing, please feel free to ask. |
|
|
FYI, in case you didn't know, the Preferences button sometimes appears at the top of the screen. Seems to depend on which site I am viewing. It's no big hassle of course, but I thought you might like to know. cheers, ~v |
|
|
CP, Your effort and replies are much appreciated. The behind-the-scenes downloads that you too have verified are not malicious, as far as I have been able to determine. They are however, a sign of MU's odd behavior.
|
|
|
Thanks Yah, This is just as I had suspected - that perhaps each MU link on the page was attempting to be downloaded. That's pretty scary when I think of some of the pages I view!
Does this mean that if I was logged out of MU in megamanager and in the browser, TCLC should be able to safely check the MU links? thanks for hanging in there with me on this one. |
|
|
@CP,
|