THIS IS A STATIC MIRROR OF USERSCRIPTS.ORG - LOGINS DO NOT WORK
Large

uso - Count Issues

By Marti Last update 21 hours ago — Installed 6,284 times.

ERRATA

in
Subscribe to ERRATA 11 posts, 2 voices



Marti Script's Author
FirefoxX11

Bugs go here

 
Marti Script's Author
FirefoxX11

GitHub is currently returning a 301 Moved Permanently status for @requires to their repositories. If this situation is not resolved with them later this evening I will be mirroring those libraries to a more reliable repository. Sorry for the inconvenience and delay.

 
Alek T Scriptwright
FirefoxWindows

Hiding the Share header in the sidebar doesn't hide the Google +1 item. It's being difficult by being in its own iframe.

 
Marti Script's Author
FirefoxX11

Alek T wrote:
Hiding the Share header in the sidebar doesn't hide the Google +1 item. It's being difficult by being in its own iframe.
Yes... I usually have google disabled by NoScript so I usually never see it. Goo being difficult is typical... one set of their scripts checks to see if the other is enabled and if not it redraws it... quite invasive usually ;)

I'll see if I can kill it at some point without major repercussions to other scripts, script injection order, or find you a different solution. Technically "Favorite this Script" is also part of Share, but I didn't want that removed for compatibility with other scripts. I and some others use it as an anchor. I've been thinking about this for a realllllllly long time since it's walking a tight rope. Thanks for the kind nudge. :)


Guess I'll settle on this next releases solution... let the User decide ;) Let me know how it works for you. :)

 
Alek T Scriptwright
FirefoxWindows

Favorite this Script is the only part of the Share block I use, since I subscribe to the RSS feed of my favorite scripts so I know when they're updated.

Hiding the Google +1 works fine with 0.18.2, and doesn't seem to break any other scripts so far. Thanks for the quick fix.

 
Marti Script's Author
FirefoxX11

Alek T wrote:
Thanks for the quick fix.
Welcome! :) Some more bug fixes are coming shortly... seems that I missed a few things during the last site revamp.

 
Alek T Scriptwright
FirefoxWindows

With 1.0rc1 installed, I get this message with Ghostery installed when I load nearly any script's About page.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: chrome://ghostery/content/ghostery-common.js:1206

Not sure if it's this script's fault or Ghostery's, but I've used both of these together pre-1.0rc1 with no slowdown.

 
Marti Script's Author
FirefoxX11

Alek T wrote:
With 1.0rc1 installed, I get this message with Ghostery installed when I load nearly any script's About page.
Odd... I haven't run that Add-on in a while... I will give this a shot in tandem momentarily. This top-level script is in pure strict ECMAScript 5/6 mode now... so I'm not sure if there is an upstream Moz issue or maybe even GM. Error/Web console would report anything unusual usually in pure strict. Tested/rewrote everything on Mozs' 64bit FF 21.0b1 and 21.0b2 under Linux, and retested under WinXP in FF20 32bit Moz release.

  • Do you have Auto Show enabled for Lost and Found or not? If so try it disabled and manually trigger it. Since I moved the preference names around and renamed a few this should have reset GMC to defaults... does here anyways. :)
  • Is this just on the scripts homepage? e.g. what happens on the Source code tab?
  • What CPU speed do you have? Multiple cores? (ballpark)
  • Which browser version?

Give me at least a few days of running Ghostery and I'll get back to you here. Thanks for the report.


Preliminary tests on a really large script... no popup. This is with JsCode enabled and manual trigger. JsCode can sometimes run into this on deep obfuscated scripts but usually the too much recursion error trap in upstream Moz should catch those now and/or prompt to continue (usually twice for the largest script I've encountered on a 2 core and a 4 core). With Auto Show enabled... cleared cache... still no popups on that script.

Additional preliminary tests under XP... same result... there is the usual large pause on that script but no failures or alerts... XP I'm running Ghosterys cookie manager too since I only have cookie culler on there. Are you running any of the Cookie managers that Ghostery says could cause performance issues?

I'll run with these systems for a day or two but I can't reproduce it immediately. I did look into Ghosterys code at that line and it's a while loop that is constructed unusually and does apply to strict vs loose... but I'm pretty sure that applies to URL pattern matching and dissection. If Ghostery wanted to they have access to XPCOM libraries to do that for them or they could use a created document element somewhere of an anchor tag and then just let Mozilla handle the methods.... seems like something they should probably let the XPCOM handle imho since the regular expression handling in JavaScript is quite a bit slower than native C++ (e.g. Firefox itself). Those are some seriously complicated regular expressions! ;) :) I can see a possible lock up with single threaded execution since it has multiple braces and conditionals in JavaScript.

Target code (ghostery-common.js):

...
parseUri: {
  options: {
    strictMode: false,
    key: ["source","protocol","authority","userInfo","user","password","host","port","relative","path","directory","file","query","anchor"],
    q:   {
            name:   "queryKey",
            parser: /(?:^|&)([^&=]*)=?([^&]*)/g
    },
    parser: {
            strict: /^(?:([^:\/?#]+):)?(?:\/\/((?:(([^:@]*)(?::([^:@]*))?)?@)?([^:\/?#]*)(?::(\d*))?))?((((?:[^?#\/]*\/)*)([^?#]*))(?:\?([^#]*))?(?:#(.*))?)/,
            loose:  /^(?:(?![^:@]+:[^:@\/]*@)([^:\/?#.]+):)?(?:\/\/)?((?:(([^:@]*)(?::([^:@]*))?)?@)?([^:\/?#]*)(?::(\d*))?)(((\/(?:[^?#](?![^?#\/]*\.[^?#\/.]+(?:[?#]|$)))*\/?)?([^?#\/]*))(?:\?([^#]*))?(?:#(.*))?)/
    }
  },
  parse: function (str) {
    var     o   = ghostery.prefs.parseUri.options,
    m   = o.parser[o.strictMode ? "strict" : "loose"].exec(str),
    uri = {},
    i   = 14;

    while (i--) uri[o.key[i]] = m[i] || ""; // <-- Current line at 1206

    uri[o.q.name] = {};
    uri[o.key[12]].replace(o.q.parser, function ($0, $1, $2) {
            if ($1) uri[o.q.name][$1] = $2;
    });

    return uri;
  }
},
...

Just as a FYI... Count Issues is around 30ish% faster now because I optimized some logic to not be so redundant. Anyhow... I will report back in a few days... try a clean profile too... mine is really "well used" so I don't think it would be that but I don't know on your end. I usually run Count Issues near the start of GMs script execution order to allow time for the asynchronous functions to complete while others are still running afterwards.

 
Marti Script's Author
FirefoxX11

Alek T wrote:
With 1.0rc1 installed, I get this message with Ghostery installed when I load nearly any script's About page.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: chrome://ghostery/content/ghostery-common.js:1206

Not sure if it's this script's fault or Ghostery's, but I've used both of these together pre-1.0rc1 with no slowdown.
Well... I've been running both continually since here and I haven't even seen a popup like this yet. I'm not sure what is going on with your system. :\ If you ever answer my questions above I may be able to simulate or find a similar machine to reproduce. :) You may want to run CCleaner or similar and make sure your machine is free and clear of spyware and "crumbs". Updated virus scanning is also a good option to improve speed. Defraggler and AutoRuns is what I use on Windows HDDs to optimize startup times... perhaps you are running out of memory or HDD space.

For now I'm virtual tagging (labeling as some call it) this as WORKSFORME . I'll keep my eye out, long term, for this issue by keeping it OPEN . I will keep trying both on the machine networks that I maintain throughout the month. The only thing I can think of is that your machine may not be able to parse the Lost and Found, twice, fast enough. In the meantime, if you need to, reinstall 0.24.0 since that version still works mostly in ECMAScript 4/5 mode.

Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0
Greasemonkey 1.8.0.x
Ghostery 2.9.3

 
Marti Script's Author
FirefoxX11

@Alek T,

Has Ghostery 2.9.4 resolved your issue? This seems like a pretty massive update. I've tested both on a few more machines and I still can't reproduce your issue.

 
Marti Script's Author
FirefoxX11

@Alek T,

In Ghostery 2.9.5 there seems to be a fix that applies to your situation which could possibly be affected by @resource in upstream GM.

- Resolved an unresponsive script issue when parsing image data:uri sources
Since I'm not able to replicate this issue at all anywhere on dozens of machines over the last month... I think I'm going to close it. I'll keep my eye out when I test against Ghostery but since Ghostery appears to block most sites that have CSE I can't run it full time on the target machines.

Virtual tagging as CLOSED . Thanks for the report. :)