ERRATA

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 Twrote:
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. :)

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.

Alek Twrote:
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](https://addons.mozilla.org/firefox/addon/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.

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.

Alek Twrote:
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.

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.