InformAction Forums

I'm not sure if this counts as a bug since it requires the user to write a (probably pretty bad) regular expression.

Tested on Ubuntu 10.10, Firefox 3.6.13, and NoScript 2.0.9.7 and 2.0.9.8rc1. This seems to have happened for the past few versions as well. You need a Facebook account to verify this, but it might happen on other sites too.

1. Create a new profile and install NoScript.
2. Add the following Anti-XSS exception rule: ^https://(.+\.)+ufl\.edu/
3. Allow scripts from facebook.com and fbcdn.net.
4. Go to facebook.com and log in.
5. Go to https://www.facebook.com/ (you can enter the address manually or have NoScript force SSL for the site).
6. Firefox stalls and displays the unresponsive script dialog with regards to chrome://noscript/content/RequestWatchdog.js:480.

In the profile I use for day-to-day browsing, the result is worse; Firefox always hangs without even warning about an unresponsive script. I remove that particular regex, and everything is fine.

So, maybe this isn't a bug - I understand that operations involving regexes can be costly, and this one that I wrote could probably be more specific - but it's only been happening for the past few versions of NoScript.

XSS exception handling has not been changed in a VERY long time, so I doubt "a few" version ago things were different.
If anything really changed, I would be more inclined to look at Firefox's regexp implementation.

However, it's well known that badly written regexps can turn into even infinite or pseudo-infinite loops, so you're correct in saying this is not a NoScript bug.

If I understand your intent correctly, the following is both more specific and safer (yours would match
https://some-completely-unrelated.website.com/some/path/ufl.edu/some/other/gibberish
for instance):