Slashdot Mirror

Between Firefox 4 and Firefox 6. Are they even doing releases anymore or just bug fixes?

Why is the "calendar" feature of Mozilla named "lighting"?

Mozilla actually had a specialized calendar program named Sunbird (doesn't fix your issue with non-descriptive names). Lightning actually makes sense since it is a Thunderbird extention. http://www.mozilla.org/projects/calendar/sunbird/

Conpare: InternetExplorer, PaintShopPro, MediaPlayer Compare to: Mozilla, Gimp, VLC

I'll bite
IE self identifies as Mozilla, PSP isn't a professional program
GNUImageManipulationProgram, VideoLanClient

Until it can do basic repeating intervals I can't recommend it.

Check out the Lazarus extension for Firefox... it's pretty nice to have if you (like me) are prone to accidentally closing tabs.

This is false.

https://developer.mozilla.org/en/Using_web_workers

Supported by Firefox 3.5+, Safari 4+, Chrome 3+, and IE 10.

they were the one major player unable to handle a necessary security task.

I don't know "unable" means in your world, but it my world, it means "not able to be done." Were they slower than others? Yes. Were they the last one? No. Depending on who you consider "a major player", they weren't the last. If you deal with servers, Redhat and Ubuntu also patched the same day. MS only patched 3 days before Apple.

• Ubuntu: September 9, 2011
• Apple OS X: September 9, 2011
• Redhat: September 9, 2011
• FreeBSD: September 6, 2011
• MS: September 6, 2011
• Google Chrome: September 5, 2011
• OpenBSD: August 31, 2011
• Mozilla: August 31, 2011
• Debian: August 31, 2011
• Android: no date
• iOS: no date
• WP7: no date
• BBM: no date

Global-by-default-unless-declared for variables is a recipe of disaster.

ES5 strict mode already disallows that.

If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces

The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".

Syntax for lambdas is overly verbose

There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.

"new Boolean(false)" is considered true in a conditional expression..

I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.

While we're at it, what's up with the whole separation into primitives and objects?

I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.

Here is Mozilla's page on it. It appears that it just sends a "don't track me, pls" HTTP header if you enable it.

If only a handful of people use it, I can imagine that larger and more-responsible advertisers might interpret that as an opt-out. I can't imagine them agreeing if it gets more pervasive, though. Many currently have opt-out methods, but they're deliberately a bit harder to use and less automatic. I would imagine that at the least, they'll try to set up some requirement for additional confirmation of the opt-out.

And of course many advertisers will just ignore it: voluntary implementation of opt-out functionality will never catch the worst offenders.

If you can trust a CA-signed certificate for https://addons.mozilla.org/ why not one for https://citibank.com/ or https://mail.google.com?

Ultimately, if all the browsers start supporting notaries directly and ship with a list of major trusted notaries this won't be a problem. But bootstrapping a trust network to replace a presumably untrusted PKI while using that same PKI to validate the code you're using to replace it... It's sort of unfounded.

But what about Honest Achmed?

I realise the bug and surrounding blog hype of said bug is humorous, but it really is a legitimate question: what makes Honest Achmed any more (or less) trustworthy than a CA?

The correct answer, by the way, is nothing. Honest Achmed is just as trustworthy as any other CA. Which is why the concept of a CA is only idealistic; in practise it solves nothing other than providing a way for some already rich bastard to become more rich. SSL certs signed by CAs isn't about ensuring trust, it's about money.

Amusingly relevant captcha phrase for this reply: amenable.

And Mozilla gave these jokers a pass while raking CACert across the coals.

That distinction is very instructive as to the real motivations of the PKI industry.

Well, here are the requirements for a CA's certificate to be included in Mozilla products. In particular, they require an independent audit of the CA's policies and internal operations. Presumably other browser vendors follow similar procedures.

Now I get it! He was not a hacker, or a cracker. He was an independent auditor!

Well, here are the requirements for a CA's certificate to be included in Mozilla products. In particular, they require an independent audit of the CA's policies and internal operations. Presumably other browser vendors follow similar procedures.

For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed.

Certificate Patrol for Firefox.
"This add-on reveals when certificates are updated, so you can ensure it was a legitimate change."
The UI is good too. Certificate Patrol, along with NoScript and Cookie Monster, is a major reason to use Firefox.

X.509 handling is largely neglected by UI designers, not just in web browsers.
Sometime clients actually have options like "[x] Accept all certificates".

For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed.

Certificate Patrol for Firefox.
"This add-on reveals when certificates are updated, so you can ensure it was a legitimate change."
The UI is good too. Certificate Patrol, along with NoScript and Cookie Monster, is a major reason to use Firefox.

X.509 handling is largely neglected by UI designers, not just in web browsers.
Sometime clients actually have options like "[x] Accept all certificates".

Can we start to get some distributed trust systems in place, instead?

I suggest getting some Perspectives on the whole issue. Not only does it bypass warnings about self-signed certs, it gives an extra warning if a secure site looks hinky despite a valid cert.

Several addons like FoxLingo makes that quite easily, actually. With Chrome and Opera you can even translate the whole page, tho I don't know how that works if there's several languages mixed.

2) Pop a huge warning if the cert changes, even if the CA signs the new one. This is the really important part.

There are firefox extensions which do just that: Certificate Patrol. If a certificate changes without reason (i.e. while still being far from expiration), a warning pops up.

However, the problem with this approach is again stupidity of the webmail operators and ignorance how certificates work.

Some large webmail providers (yahoo, google, ...) who have load-balanced banks of servers sometimes have half of their servers with one certificate, and the other half with another (possibly even signed by another CA...), resulting in lots of false alarms while you unknowingly switch between both, triggering lots of false "Certificate patrol" alarms diluting their value...

Gosh, how hard is it to switch over all servers at once? Does it really have to take a week?

http://www.mozilla.org/en-US/firefox/6.0.1/releasenotes/

Expand "what's new" to see the change.

Update immediately if this is worrysome to you.

These certs were revoked yesterday in an out-of-band patch.

Compared to the mainstream of Java/C++, JavaScript's prototype-based OO is pretty strange.

People put up with language weirdness for two reasons:

* It's the only game in town (JavaScript and browser extension, Emacs Lisp, tcl/tk and X GUIs)
* It has something you really need/want (Lisp macros, Java JVM, C++ low-level access)

Neither of those can really be used to drive a universal GNU extension language. Wishing for it is like wishing for something to displace the x86 architecture.

Why hasn't mozilla or someone else made a simple addon for maintaining/importing CA CRL lists

CRL's are being supplanted by OCSP <WP:Online_Certificate_Status_Protocol>.

The patchset has details, but, I don't get why Mozilla's OCSP service isn't sufficient here. Mundanes aren't allowed to view this bug:

// Bug 682927: Do not trust any DigiNotar-issued certificates.
// We do this check after normal certificate validation because we do not
// want to override a "revoked" OCSP response.

Here they're hard-coding a CN check:

if (strstr(node->cert->issuerName, "CN=DigiNotar")) {
    isDigiNotarIssuedCert = PR_TRUE;
// Do not let the user override the error if the cert was
// chained from the "DigiNotar Root CA" cert and the cert was issued
// within the time window in which we think the mis-issuance(s) occurred.
    if (strstr(node->cert->issuerName, "CN=DigiNotar Root CA")) {
      PRTime cutoff = 0, notBefore = 0, notAfter = 0;
      PRStatus status = PR_ParseTimeString("01-JUL-2011 00:00", PR_TRUE, &cutoff);
      NS_ASSERTION(status == PR_SUCCESS, "PR_ParseTimeString failed");
      if (status != PR_SUCCESS ||
          CERT_GetCertTimes(serverCert, &notBefore, &notAfter) != SECSuccess ||
          notBefore >= cutoff) {
        return SEC_ERROR_REVOKED_CERTIFICATE;
      }
    }
  }

And, this is quite interesting:

// By request of the Dutch government
  if (!strcmp(node->cert->issuerName,
              "CN=Staat der Nederlanden Root CA,O=Staat der Nederlanden,C=NL") &&
      CERT_LIST_END(CERT_LIST_NEXT(node), serverCertChain)) {
    return 0;
  }
  }

I wonder what the Dutch government knows - it would imply more than a 1-off problem since the chain should provide a level of isolation.

Nonetheless, there should be code changes required for this sort of problem. Maybe Mozilla doesn't have an OCSP responder running for its roots certs yet?

My first bug report was bug 27610, so we probably overlapped.

Yes, mpt was very much around. I learned a lot from reading mpt's comments in Bugzilla. It's too bad he didn't get along with everyone.

Maybe I should tell my browser to just accept certs signed by Bob's SSL Certs and Taco Stand

Or Honest Achmed. I know his cousin Osman, he's OK.

That's for the Facebook "Like" button but this technique is also commonly used by Ad networks - I suspect you only noticed it here because HTTPS-everywhere will force the facebook connection to SSL (and AdBlock Plus won't block the Facebook "like" button normally). Certificate Patrol will then alert you to the certificate changes.

Look into using something like the RequestPolicy extension if you want more control over which off-site content gets loaded - it lets you implement a deny-by-default type policy in a similar way to NoScript; however you quickly find that a lot of sites put CSS and/or images on different domains which can be annotying - so it's worth checking out Ghostery instead (or as well as a more permissive default policy) if that bugs you.

That's for the Facebook "Like" button but this technique is also commonly used by Ad networks - I suspect you only noticed it here because HTTPS-everywhere will force the facebook connection to SSL (and AdBlock Plus won't block the Facebook "like" button normally). Certificate Patrol will then alert you to the certificate changes.

Look into using something like the RequestPolicy extension if you want more control over which off-site content gets loaded - it lets you implement a deny-by-default type policy in a similar way to NoScript; however you quickly find that a lot of sites put CSS and/or images on different domains which can be annotying - so it's worth checking out Ghostery instead (or as well as a more permissive default policy) if that bugs you.

There is a bugreport about that already: https://bugzilla.mozilla.org/show_bug.cgi?id=670622

I've been using Certificate Patrol for a while alongside Perspectives and it's pretty useful. However, it has also brought to my attention the frequency with which Google/Gmail's certificates seem to change which the links given above also highlight in the graphs.

I'm still puzzled as to why this is (and why e.g. the Gmail IMAPS certs don't seem to change anything like as frequently - more like annually) but if the certs changes frequently it diminishes the usefulness of e.g. Perspectives quite a bit. Which is unfortunate for a site like Gmail which would seem to be highly likely to be targeted for MITM.

I triaged bugs back in 2000, too. What was your username or email address in Bugzilla? :)

Nowadays my focuses are security and finding bugs.

In 2009 I wrote about how to make triage more efficient and more effective. (Tyler linked to my post). And I actually triaged a subset of bugs that way when I was tasked with bringing down the number of crash bug reports.

One of the many people that don't know about the 'Add-on compatibility reported':

https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/

That makes this easier and a way to report any issues you may have to the developers of Firefox and the add-on.

I did a search on Mozilla and effectively they have a proprietary extension that does a similar thing : https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/WeakMap , they are effectively working to standardize it with the group you mentioned.

Asa happens to be Firefox's "Product Manager", just FYI. Kicking him out will vacate that position; and judging by the bitchiness I've seen, it's hard to imagine why anyone else would want that position.

Bugs arent being fixed

I concur.

My favorite bug.

It would be better if you use the Add-on Compatibility Reporter. That way, if you find an add-on works, you can mark it so, and the guys at mozilla get to know that. But I doubt they'd work on it. https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/

Ouch. To be fair, someone on the Chrome page pointed out that

No single opensource browser can render properly this tag properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=915 (12 year old!)
https://bugs.kde.org/show_bug.cgi?id=50688
https://bugs.webkit.org/show_bug.cgi?id=3241
[let's inline Chrome's bug for slashdot's benefit: https://code.google.com/p/chromium/issues/detail?id=12094 ]

To be even fairer, IE8 from 2009 on my up-to-date Windows Seven PC has no problems rendering properly where all four OSS browsers failed.

It's such a simple logical failure too... it's a bizarre case showing that IE has some silent merits... Must be sanity-wrenching to find a bug like this prior to seeing confirmation that it's not YOUR code at fault because the once-leading browser has no issues rendering it.

I wonder how many thousands of devs around the world individually break their head per year once their corporations give the green light to move to OSS browsers, but someone notices THIS exact bug and pulls back. It's little wonder doc files and PDF distributions are so overwhelmingly prefered to HTML.

"I'm guessing that's because of lack of resources."

That sounds to many people like a reasonable guess, but it is incorrect. See this story: Mozilla Extends Lucrative Deal With Google For 3 Years.

Mozilla Foundation's audited financial statement from 2009: http://www.mozilla.org/foundation/documents/mf-2009-audited-financial-statement.pdf

First off, I never intended my post to be taken in the way that it was. Simply because there are 6000 UNCO bugs in the Firefox product does not mean that Firefox has 6000 bugs in it. Out of all those bugs, the majority are going to be duplicates of other bugs, they are going to be user error, they are going to be bugs caused by a misbehaving extension that a user installed on Firefox, and so on. Out of all those 6000 bugs, I'd estimate at most there are 1000 REAL bugs in Firefox, and that is an extremely high guess. What I was trying to say is that without going through and triaging all those bugs, we have no way of knowing which are real and should be taken seriously, and which are not real bugs. If you read https://bugzilla.mozilla.org/page.cgi?id=fields.html#status, you will see: "This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. " An UNCO bug has not be confirmed yet, it needs to be marked as NEW before it is considered a real bug. So it isn't fair to say that Firefox shipped with 6000 bugs, but more that there are roughly 2600 bugs that haven't been touched in 150 days, which is far more worrisome to me. We will never be able to have 0 bugs, but we may at least have a quick response to the bugs we do get. That is what my whole blog post was about, quick responses, and treating our reporters fairly. Unfortunately, Conceivably Tech was too eager to get a shocking headline, and so misconstrued my points. If you come back to re-read my blog in a day or two, I'll post more clarifications.

Bugs stay in "unconfirmed" status much later than would be expected. Check out https://bugzilla.mozilla.org/show_bug.cgi?id=672677 , for example. A community member (Alice White) went to the trouble of tracking down which nightly build introduced the problem, somebody from Mozilla commented that it was similar to a known issue, yet the bug stays in "unconfirmed" status.

There is an addon compatibility tool that you can use to force addons to be enabled, a lot easier and more user-friendly. It is still more of a tool for people that know what they're doing.

Also pretty sure there's some sort of functionality in the addons.mozilla.org site that will automatically update addons to declare compatibility if they don't use any APIs that were changed, or something like that.

As 13 years are not enough to handle a major bug.
They are focusing on HTML5 (which is not a standard but a draft) and leave HTML4 implementation with all existing bugs.
They think that all web pages will be rewritten in HTML5 as soon as it will land as real standard. It will instead take years.

This test exercises a situation that's very rare on the web (where by "rare" I mean that it's only been encountered in this test to my knowledge): thousands of absolutely positioned elements that are all being moved around using CSS transforms, with each one only being moved once by going from no transform to a translate transform. That's just not something anyone other than this test does. Most people who want to move an absolutely positioned element just change its .top and .left, but this test sort of went out of its way to do things the weird way.

The net result is that this test ends up hitting a rare-case O(N^2) codepath in Gecko. See https://bugzilla.mozilla.org/show_bug.cgi?id=641340 and https://bugzilla.mozilla.org/show_bug.cgi?id=641341 and https://bugzilla.mozilla.org/show_bug.cgi?id=670311 for the bugs tracking this on Mozilla's end.

Fixing these has not been a terribly high priority, since it would mostly affect this one synthetic benchmark (I say "mostly", because bug 670311 could have benefits elsewhere too).

This test exercises a situation that's very rare on the web (where by "rare" I mean that it's only been encountered in this test to my knowledge): thousands of absolutely positioned elements that are all being moved around using CSS transforms, with each one only being moved once by going from no transform to a translate transform. That's just not something anyone other than this test does. Most people who want to move an absolutely positioned element just change its .top and .left, but this test sort of went out of its way to do things the weird way.

The net result is that this test ends up hitting a rare-case O(N^2) codepath in Gecko. See https://bugzilla.mozilla.org/show_bug.cgi?id=641340 and https://bugzilla.mozilla.org/show_bug.cgi?id=641341 and https://bugzilla.mozilla.org/show_bug.cgi?id=670311 for the bugs tracking this on Mozilla's end.

Fixing these has not been a terribly high priority, since it would mostly affect this one synthetic benchmark (I say "mostly", because bug 670311 could have benefits elsewhere too).

This test exercises a situation that's very rare on the web (where by "rare" I mean that it's only been encountered in this test to my knowledge): thousands of absolutely positioned elements that are all being moved around using CSS transforms, with each one only being moved once by going from no transform to a translate transform. That's just not something anyone other than this test does. Most people who want to move an absolutely positioned element just change its .top and .left, but this test sort of went out of its way to do things the weird way.

The net result is that this test ends up hitting a rare-case O(N^2) codepath in Gecko. See https://bugzilla.mozilla.org/show_bug.cgi?id=641340 and https://bugzilla.mozilla.org/show_bug.cgi?id=641341 and https://bugzilla.mozilla.org/show_bug.cgi?id=670311 for the bugs tracking this on Mozilla's end.

Fixing these has not been a terribly high priority, since it would mostly affect this one synthetic benchmark (I say "mostly", because bug 670311 could have benefits elsewhere too).

Nice to know that they changed it from this: http://www.mozilla.org/ports/beos/

And since it works on Chrome (webkit), it should also work on Webpositive.

Fortunately there is a workaround.

The telemetry information is opt-in. So nothing is sent unless you _explicitly_ tell Firefox to send it.

If you want to see exactly what information is being gathered, https://addons.mozilla.org/en-US/firefox/addon/abouttelemetry/ will tell you.

https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/ This add-on "forces" add-on compatibility. A must have if you are trying out Fx betas, auroras and nightlies.

Why is this modded up?

You can use all of these. Actually I AM USING ALL OF THESE IN 6.0.
http://portableapps.com/apps/internet/firefox_portable
https://addons.mozilla.org/en-US/firefox/addon/febe/

1. backup your profile. If you are on windows or you can't command line on linux, use FEBE (yes there's a 3.6 version (scroll down and look in version information), yes it works cross versions), or if linux, cp -r ~/.mozilla ~/.mozillabackup to backup your profile.
2. if windows, use portable firefox. otherwise on linux download the latest executable from the site. you must backup your profile somehow in step one before you do this to allow you to revert and use your settings if you decide to keep your settings. if you are paranoid that some obscure setting wont save use a portable 3.6 and try to clone it.
3. test the new version. if you used portable firefox, you can use FEBE to transfer settings to a real install (portable versions can lag behind drastically). revert if you are pedantic, impatient to configure and install new ui extensions to fix things (like statusbar 4eva, tab mix plus, etc.), or have serious problems.

Literally, don't go apeshit about it. You can do something about it, without addons breaking. New in 6.0 is heuristics for AMO (addons.mozilla.com) plugins to be auto version bumped for beyond versions. You're just gonna whine about it and not take the time to research, nor voice your concern to mozilla, nor know all the facts. By the by, i agree, mozilla should add for enterprise and people who want stability: Stable version and rapid release version of firefox.

"I agree with you as for web pages. But write Firefox add-ons to what spec?"

The Add-ons SDK. Write to that and your add-ons won't break with updates. https://addons.mozilla.org/en-US/developers/builder Yeah. It's that easy. Write to the stable APIs of the Web and the stable APIs of Firefox. When you do that, things shouldn't break and when they do, they're very rare and can be pinned on Firefox as legitimate bugs.

I see what you did there.

Firefox extensions have a lot of access to the browser, so when features change, so does the extension API. Mozilla is working on a project called the Add-on SDK which has a stable API and provides less intrusive access to the browser. It allows for addons that work a lot like Chrome extensions. A lot of current popular extensions can probably be rewritten for this platform (though some of course still need low-level access and will have to stay extensions).