Difference between 1.10 & 2.0rc2 ?

[therube]

Difference between 1.10 & 2.0rc2 ?

Are these two different branches?
One end of life?
The same only one is #dev, the other release - with different naming?
Something else?

NoScript 1.10.x is the last serie supporting Firefox 2.0 and older browsers. It will be updated only if affected by serious security vulnerabilities (very unlikely). This will allow the upcoming NoScript 2.x series to be developed faster and better, by removing legacy compatibility code and fully leveraging the latest APIs and language features.

http://noscript.net/

[Giorgio Maone]

• 1.10.x is end of life/security mantainance mode (i.e. it won't be updated unless a vulnerability is discovered which actually increases the browser's attack surface, a la GreaseMonkey or Cooliris Preview).
• 2.0rc1 (on AMO only) is the first release not compatible with 2.0 (even though it will likely still work if forced): from now on, using Gecko 1.9 only stuff in incompatible ways (e.g. new JavaScript features, which cannot be "shimmed" like I used to do with APIs) is fair game. Aside this "statement of principles", it's identical to 1.10
• 2.0rc2 has a new feature, but it's under the hood (external filters interface has been made more flexible, by Blitzeibleiter developers request).

[piker]

First, a comment/opinion: End of life browsers and NoScript not supporting them as always now (save for security related, etc) is very sad. IMHO, the Mozilla (Seamonkey) suite prior to the newer 2.x versions were far superior and safer. They should still support and release Seamonkey 1.1.xx versions in my opinion. The newer 2.x+ is just a reimplementation of a bloated (and more often insecure version of) Firefox, since now they're both practically the same under the hood. That said, I'd still say the Seamonkey 2.x suite is probably safer and less (but not by much) vulnerable than Firefox.. Also, the lack of detailed customization and tuning in the newer 2.x suite is really too bad.

That said, it would seem that (not only NoScript version 1.10, but) version 2.0rc4 is the latest version that still works with Mozilla/Seamonkey 1.1.19 type releases.

Now, in regard to Seamonkey's latest (1.1.19) version/security release (with a still-indefinate support for future security releases) and the latest NoScript versions... The most recent/latest NoScript version that seems to work completely fine with no errors is noscript-2.0rc4.xpi (dev. release 2010-07-24)... since then, every subsequent release (2.0rc5,6,7,8 and 2.0.1rc1,2) simply breaks after a seemingly successful install for each... When either of these newer versions (not including 2.0rc4 and prior) are installed and the browser re-opened, noscript is disabled and spews the typcal error (badinstall) and the console produces at least the following two errors/pointers:

INCLUDE DNS: SyntaxError: missing { before function body
INCLUDE Main: ReferenceError: WAN is not defined

I tried looking into the xpi/jar and component (.js) files to see if I could find a simple solution/workaround but gave up... Ultimately, my question is as follows:

1 - Are these errors a result of newer functions/api/code that exists only in the newer 2.x Seamonkey/Mozilla/Xulrunner suites (and not in the prior versions (1.1.19...))? ..or
2 - Is it possible that this is an issue that you can modify/fix for us users that are still reluctant to "upgrade" the the currently undesirable 2.x versions of Mozilla/Seamonkey?

...as always, thanks for your time and effort and increasingly superb products and excellence!

[therube]

1 - likely support code that was removed & will continue to be removed from 2.0, that had existed in 1.10
2 - since 1-, & since the reason for the split is to segregate old browser/old NoScript from new browser/new NoScript, not going to happen.

And as much as I liked SeaMonkey 1.x, it is the right decision. Furthermore, every time a SeaMonkey specific bug is brought up, I'm sure Giorgio curses (under his breath, damn SeaMonkey!) as it is .


(I don't use SeaMonkey Mail or News. Chat only limited, but what it does is fine for me. Composer, once in a blue moon.)

IMO, the 2.x browser is much improved over 1.1.x.

While I have never really investigated Mail (or Thunderbird), my impression is that they are not best in class applications, so should not even be included. Something better should. Ditto for Composer. Though Kompozer (updated & supported) is supposed to be ported back into the suite at some point.

Anyhow, even though SeaMonkey 2.x is picking up "firefox-ities", it is still better then SeaMonkey 1.1.x & far better then FF. SeaMonkey really has no option but to follow on the coattails of FF. (At some point, I'll probably ask Kairo if it doesn't make sense to develop SeaMonkey as a shell, on top of FF, with the ability to use plugins for mail, editor, & the like. Would seem to me to it could make more sense. Though I know nothing of what is involved in something like that.

[piker]

Hi rube, thanks for the response/opinions... which I almost fully agree with on all counts.. My partner here uses Seamoney 2.x here and it's also the browser that I recommend everone else use. My experience/observations with it (being more like FF) aside from being potentially bloatish and too-GUI-with-lessened-preference-or-customization-options are the similarly limited newer version of many of the extensions available for it.. although thats perhaps countered by the increased number of extensions/plugins continually available for it and no the 1.x suite... I'm afraid that soon enough that I will be forced to "upgrade", if not for complete-EOL and lack of continued support on their end, the ever-important NoScript and added functionality will probably be the first reason. As one of many (RPM/Linux) package maintainers, Seamonkey being one of them, I'll no doubt have to spend an increased amount of time re-streamlining the newer version as well as attemping to re-implement more control of behavior, customization and preferences. Bleh.

Regarding email.. unless necessary, I stick to console-based mutt first, before KDE's Kmail (customization is key!) then Seamonkey's mail. As for chat, and as (patheticly admitting) a long-time oldschool IRC admin/oper, I still prefer ircII via console... In regards to Composer.. I probably agree that Kompozer would be my first choice over Seamonkey's composer, which I never really fully appreciated anyways.. that said.. I still, however, religiously use console-based text editors for any/all html development, namely vi/VIM. .. Obviously my concern and most used Mozilla/Seamonkey component is the browser. Which, BTW.. thanks to not just NoScript, but FlashGot as well, allows me to ultimately create highly useful functionality in various ways that would otherwise be non-existant, (talking about FlashGot that is).. including several not-intended utilities, lookups, and various other tools and critical functionality.. which in the end is probably one of the only saving/worthy factors allowing me to convert to Seamonkey 2.x in any comfortable-resembling way. Noscript and Flashgot can't be praised or more necessary than can be expressed. We really owe you guys (supporters) and Giorgio a huge debt of gratitude.

Aside from hoping for a last-time implementation of the currently released features of NoScript 2.x into our "legacy" Seamonkey (not including already-stated security-related ones), thanks for your comments, and potentially any further insight as to my previous post from Giorgio once he reads it...

[Giorgio Maone]

1 - Are these errors a result of newer functions/api/code that exists only in the newer 2.x Seamonkey/Mozilla/Xulrunner suites (and not in the prior versions (1.1.19...))?

Yes, those specific "Syntax Error" instances are due to new JavaScript (ECMAScript, actually) constructs which make the code more maintainable and potentially faster, but are not supported by older SpiderMonkey versions.
therube is correct nonetheless, the "shim" code which was there only for legacy compatibility is being removed every time I code something in the area containing it, in order to reduce the bloat and potential for bugs, increase the performance and make room for new features.