mozilla

Sunday, November 29 2015

[14:58:42] matt [wronka.org]/Psi+ I wish Mozilla would stop playing with the lock icons and return to showing the schema.

Friday, February 13 2015

Mozilla BUY TAX SOFTWARE FireFox
[01:57:22] matt [wronka.org]/Psi+ Recently—last week or so that is—I noticed my "speed dial"/recently viewed sites list on my desktop copies of Mozilla FIreFox were cleared. This happened to coïncide with rebuilding nightly. At first this was an annoyance, when everything was replaced with links to Mozilla and open source pages. After using the browser for a bit, I got one bookmark back on the page (oddly, something I *hadn't* visited that day); and now after about a week, I've got the first three and the final (15th) spot as pages I've visited.

In addition to those, a tab for the Mozilla Marketplace and nine other Mozilla links: I now have a tab for a tax package. I'm not happy with you Mozilla. Basically, I'm saying the same thing to you that you are to your users.

Friday, February 6 2015

Sunday, June 16 2013

WTFWG
[01:54:25] matt [wronka.org]/navic The WHATWG can take a good idea and make it useless. Take for example their "willful violations":


A valid e-mail address is a string that matches the email production of the following ABNF, the character set for which is Unicode. This ABNF implements the extensions described in RFC 1123. [ABNF] [RFC5322] [RFC1034] [RFC1123]

email = 1*( atext / "." ) "@" label *( "." label )
label = let-dig [ [ ldh-str ] let-dig ] ; limited to a length of 63 characters by RFC 1034 section 3.5
atext = < as defined in RFC 5322 section 3.2.3 >
let-dig = < as defined in RFC 1034 section 3.5 >
ldh-str = < as defined in RFC 1034 section 3.5 >

This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition.

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/


Which as resulted in bugs like 791069 against Firefox by users expecting a valid eMail address to be a valid eMail address: https://bugzilla.mozilla.org/show_bug.cgi?id=791069

If you want to fix this locally, so it actually serves its purpose, I've got two patches you can apply locally: http://matt.wronka.org/stuff/projects/icpp/mozilla/

The second is the more-correct patch, and will also help if you happen to have a non-ASCII local part. It sounds like even with this applied, if you have a long domain name (more than 63 characters) Mozilla might complain but I haven't verified this, just looked at the comments in the code and bugzilla.

Wednesday, June 22 2011

[17:42:22] matt [wronka.org]/Psi.dementia WTF Mozilla? You want me to auto-update, but then you push a bunch of plug-ins enabled in the new version which weren't enabled in the previous? Asa, what do you think? http://weblogs.mozillazine.org/asa/archives/2010/11/why_do_they_think_th.html