You too can become a beta Firefox User!

[dhouwn]

Thinking about how I am using the dev version of NoScript since ever and about how some people gere do the same because there is really not much difference, I guess the same could be said about the Firefox Beta. That features have baked only at least 6 weeks before reaching Beta instead of 12 hardly noticeable (on top of that features bake quite some time on specialised branches and then the nightly branch for quite a while, also bigger features [e.g. SPDY, Azure] are often shipped deactivated per default at first) but you do get stuff earlier (which includes security fixes) and you can help Mozilla and probably also NoScript by using this version.

[deep_commercial_voice]So why are you not using Firefox Beta yet?
Get it now for free from: http://www.mozilla.org/firefox/beta/
Be β![/deep_commercial_voice]

/edit: For those who are not quite see through the Firefox release process and all the channels, see: http://hacks.mozilla.org/2012/05/firefo ... -channels/

[Tom T.]

Ummm, because an entire browser is much more complex than a single add-on?
I would have far less clue about where to look for the cause of a problem if one occurred?
It's a lot easier and faster to install a NS stable release over or in place of a dev build than to install an entire browser if I don't like the beta?

Since the betas may be changing more frequently, there may be features, about:config prefs, etc., of which I'm unaware, and may need configuation? New features in NS are generally defaulted to a mode that is satisfactory for most users.

Finally, because I don't trust MZ not to add horsepoop like geolocation without telling me, or changing the default to "enabled" without telling me, and I don't have time to plow through the Release Notes of every nightly or weekly or whatever build? It's bad enough putting out an entire new stable release every six weeks or two months or whatever.

NS Release Notes (changelog) are usually small in number, and most require no action on the part of the user.
The changes generally enhance the security (and incidentally, the privacy) of the user, which is not always true of Firefox.
Regressions in NS dev builds of course occur, but not often.
[/soapox]

[dhouwn]

It's a lot easier and faster to install a NS stable release over or in place of a dev build than to install an entire browser if I don't like the beta?

The installation of a release Firefox version probably takes less than a minute (at least for me). Also, you can have multiple installations side-by-side.

Since the betas may be changing more frequently, there may be features, about:config prefs, etc., of which I'm unaware, and may need configuation?

Finally, because I don't trust MZ not to add horsepoop like geolocation without telling me, or changing the default to "enabled" without telling me,

No new features are added to beta versions, only possibly removed/disabled but would normally already happen on the Aurora channel. The difference between beta version with different major version is naturally about the same as between release versions.
How would the points you mentioned apply to beta versions but not to the release versions as well?
Geolocation would be an example for a service that is opt-in, since it asks you every time before using it on a site for the first time. I am pretty sure that it wouldn't reach the beta audience in a state where it was enabled but not opt-in, since the beta version is already meant to be in a configuration state that would be also considered suitable for the release version.

[Tom T.]

It's a lot easier and faster to install a NS stable release over or in place of a dev build than to install an entire browser if I don't like the beta?

The installation of a release Firefox version probably takes less than a minute (at least for me). Also, you can have multiple installations side-by-side.

I have SxS already. Not going to bloat the HD with four or five versions. I'd consider a portable version on a flash drive, but IIUC, PortableApps.com doesn't do betas. And the configuration of any new install (Options, about:config changes, etc.) is a *lot* more than a minute -- at least, for those of us who care.

No new features are added to beta versions, only possibly removed/disabled but would normally already happen on the Aurora channel. The difference between beta version with different major version is naturally about the same as between release versions.

"about" is the key word.
And if there is no difference at all between beta and release, then what is the point of all of you beta testers giving feedback, of which there apparently is none?

How would the points you mentioned apply to beta versions but not to the release versions as well?

Presumably, they think they have most of the bugs ironed out in the release version. If they thought the beta was bug-free, it would be a release instead, what with all the Aurora/nightly testers.

Geolocation would be an example for a service that is opt-in, since it asks you every time before using it on a site for the first time. I am pretty sure that it wouldn't reach the beta audience in a state where it was enabled but not opt-in, since the beta version is already meant to be in a configuration state that would be also considered suitable for the release version.

Sorry, but one of us has incorrect memories. I seem to remember that geo.enabled was intended to default to true, until massive angry feedback prompted the change to false. Please check Bugzilla and the dev channels, etc., to see if this is not so.

Therefore, there is no reason not to believe that they might not change it back (and that's just one example). Were they to do so, perhaps the beta testers would protest. If it makes it through to the release version, well, we're just supporting my dislike of the entire 4+ direction and philosophy.

I did make my opinions known when 3.0 came out. They were not just ignored, they were shouted down with derision from MZ people.
Since their minds are already made up, why waste my time testing and reporting?

And I don't like the da*n thing anyway.

All IMHO. YMMV.

[dhouwn]

And the configuration of any new install (Options, about:config changes, etc.) is a *lot* more than a minute -- at least, for those of us who care.

Huh? You could just use your original profile(s), no need for new one(s).

No new features are added to beta versions, only possibly removed/disabled but would normally already happen on the Aurora channel. The difference between beta version with different major version is naturally about the same as between release versions.

"about" is the key word.

In what way? Both have features that were normally added in a 6-week window (with the exception of small, unproblematic ones or security-related ones that might sneak into Aurora).

And if there is no difference at all between beta and release, then what is the point of all of you beta testers giving feedback,

There is not much difference in terms of stability, good for day-to-day surfing, should there still be an issue (let's an unusual issue with an intranet site) then it would be great if reported earlier. Aurora on the other hand is not that great in terms of stability, since it comes pretty much directly from the nightly branch.

[…], then what is the point of all of you beta testers giving feedback, of which there apparently is none?

There is no feedback? I don't understand. Ah you mean the difference between beta and release, well, the feedback of the users influences how much of a difference there will be. Certainly there will be some, but compared to what changes between e.g. nightly and aurora it's minuscule.

How would the points you mentioned apply to beta versions but not to the release versions as well?

Presumably, they think they have most of the bugs ironed out in the release version. If they thought the beta was bug-free, it would be a release instead, what with all the Aurora/nightly testers.

This way the time for testing is twice as long as development (or more precise twice the time features could get included), also like I said, Aurora is (esp. at the beginning of a cycle) not as stable for everyday use, but testing something in day-to-day environment is important.

Sorry, but one of us has incorrect memories. I seem to remember that geo.enabled was intended to default to true, until massive angry feedback prompted the change to false.

geo.enabled controls the whole feature. The default now is set to true, i.e. it is enabled. Still it's asking before doing the geolocation request and sending the result to a site, thus it's opt-in.


Cross-quoting now:

And not betas, which may have security vulns.

You mean because of new features? Fair point. But on the other hand, you would also get security fixes earlier. Which would address one of your earlier criticisms of the fixed-length cycle:

Firefox formerly was superior in safety to IE even in updating. MS would await Patch Tuesday, even if the patch were ready three weeks earlier.

There are about 3-5 beta releases a cycle, considering that security fixes can land anytime in this period* that would make the exploit window you were talking about in the other thread about less than a third.

* as can be seen at http://hg.mozilla.org/releases/mozilla-beta where certain links in the commits lead to bug reports with restricted visibility.

[GµårÐïåñ]

I don't want to get in the middle of this but a quick note, you can kill Geo permanently so it won't ask AT ALL.

Just go to about:config and flip this: geo.enabled;false then you don't get that asinine and painfully annoying prompt each time the site wants you damn location.

[Tom T.]

And the configuration of any new install (Options, about:config changes, etc.) is a *lot* more than a minute -- at least, for those of us who care.

Huh? You could just use your original profile(s), no need for new one(s).

This contradicts your advice or suggestion to run them side-by-side.

[…], then what is the point of all of you beta testers giving feedback, of which there apparently is none?

There is no feedback? I don't understand. Ah you mean the difference between beta and release, well, the feedback of the users influences how much of a difference there will be. Certainly there will be some, but compared to what changes between e.g. nightly and aurora it's minuscule.

Perhaps relatively minuscule by comparison, but that does not mean "insignificant" or "of no effect".

Sorry, but one of us has incorrect memories. I seem to remember that geo.enabled was intended to default to true, until massive angry feedback prompted the change to false.

geo.enabled controls the whole feature. The default now is set to true, i.e. it is enabled. Still it's asking before doing the geolocation request and sending the result to a site, thus it's opt-in.

Sorry, I don't trust such things, whether due to careless or faulty design that allows leakage; to deliberate scamming; or to the fact that the mass of users may not have any idea just how badly this can damage their privacy over time should they allow it. It's malicious invasion of privacy, for the benefit of "targeted advertising", and of much less user benefit than they pretend.

Cross-quoting now:

And not betas, which may have security vulns.

You mean because of new features? Fair point. But on the other hand, you would also get security fixes earlier. Which would address one of your earlier criticisms of the fixed-length cycle:

Firefox formerly was superior in safety to IE even in updating. MS would await Patch Tuesday, even if the patch were ready three weeks earlier.

There are about 3-5 beta releases a cycle, considering that security fixes can land anytime in this period* that would make the exploit window you were talking about in the other thread about less than a third.

When a vuln is discovered, or reported and confirmed, I'd like to see a patch developed, extensively tested internally across many circumstances and setups, and released ASAP, either as a decimal bump like F 2/3 did, or as a patch as MS does, although not once-a-month, but ASAP.

Issuing a new beta for a patch delays the process, in case other things have changed in that beta.
If there's a vuln in 12.0, hold everything else, get it fixed, and issue it as 12.0.1 or whatever, after sufficient internal testing. No reason that beta testers should be protected sooner than the rest of us.

Say what you will about MS, they didn't issue IE 6.1beta to fix a vuln. They issued a patch, and that was that. (aside from previous complaint of batching them, even with known exploits.)

Bottom line is that I don't want to donate any of my time to developing a project that IMHO is headed 180 degrees in the wrong direction.
It's already proven that they'll ignore feedback that doesn't suit their predetermined wishes, so why put myself to any more trouble?
I'll support NS on F4+, but have no intention of "supporting" F4+ in any manner whatsoever. Firefox, once clearly the best choice, is now merely the lesser of all evils, and that is substantially due to NS's full functionality.

All personal opinion, not reflective of the forum, its developer, or anyone else but myself.

Just go to about:config and flip this: geo.enabled;false then you don't get that asinine and painfully annoying prompt each time the site wants you damn location.

Uh, yeah, actually I knew that, Brother, and of course, did it immediately. The fact that it defaults to true; that most users never go near about:config (look at the dire warnings the first time, or every time, that you do), and that one should have to do that are despicable, IMHO. At least, it should default to false; ideally IMHO, this espionage "feature" shouldn't exist. 99.99% of the time, I have absolutely no need for a site to know my exact location. The 0.01% of the time that I do (getting directions to a place with which I'm not familiar), I can type that in in a few seconds. And I always alter the true present location slightly.

[dhouwn]

This contradicts your advice or suggestion to run them side-by-side.

I meant having installations side-by-side, so in case you want to downgrade from the beta you could then just switch to the installation on the release channel, maybe update if necessary, and that's it.

Perhaps relatively minuscule by comparison, but that does not mean "insignificant" or "of no effect".

It was at least insignificant to me from my experience.

Bottom line is that I don't want to donate any of my time to developing a project that IMHO is headed 180 degrees in the wrong direction.

Sad to hear that.

[Tom T.]

Bottom line is that I don't want to donate any of my time to developing a project that IMHO is headed 180 degrees in the wrong direction.

Sad to hear that.

I assure you that I'm even sadder that I feel compelled to say that.

[Thrawn]

Bottom line is that I don't want to donate any of my time to developing a project that IMHO is headed 180 degrees in the wrong direction.

Sad to hear that.

I assure you that I'm even sadder that I feel compelled to say that.

Not to mention that the only other likely candidate for NoScript is Chrome/Chromium, which of course you hate, loathe, and despise. And although I would touch Chrome with a ten-foot pole, I don't blame you. Although Chromium might not be as bad as Chrome?

(And I agree that Mozilla has instituted a 6-week downgrade cycle.)

Has anyone had any experience/success using NoScript with other Gecko-based browsers?

[dhouwn]

Has anyone had any experience/success using NoScript with other Gecko-based browsers?

therube can confirm that NoScript works fine on SeaMonkey.

[Thrawn]

Looks like people are using NoScript on Pale Moon:

http://forum.palemoon.org/viewtopic.php?f=3&t=226
http://www.wilderssecurity.com/showthread.php?t=317322

Based on Firefox code, but retaining/restoring 3.x interface, and removing some features like parental controls and accessibility features. It's Windows-only, so I can't easily test it, but Tom may be interested.

ETA Betanews review sounds promising, as do the Pale Moon goals and release schedule.

Seriously, just from reading the documentation, this browser sounds like Fx 4+ done right. The (sole) developer still supports the 3.x branch, too. I'm going to try it via Wine.

[dhouwn]

Added hopefully helpful link to those who want to learn about the channels and the release cycle to original post. Interestingly, they recommend Firefox Aurora for web devs there.

[therube]

Not sure what to make of this?

... Pale Moon will be updated only for select and relevant updates of the Firefox source code.

This also means that Pale Moon will not be built based on beta, release candidate, milestone, or other development releases of the Firefox source code (there will not be any Pale Moon "nightly", "aurora" or "beta" builds available to the public). Only relevant "Release" source code will be used to ensure stability.

That being said, Pale Moon may, on occasion, have intermediate releases to fix known issues in the Pale Moon browser specifically before a new release version of Firefox code is available.

http://www.palemoon.org/info.shtml

[dhouwn]

I guess the Pale Moon developer will cherry-pick post-X changes and release an update for the Pale Moon version based on Firefox X every now and then.