firefox

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.

Lollipop/ART issues; Firefox Weave
[18:37:08] matt [wronka.org]/Psi.cor I've switched back to Android 4.4 (CM-11, "Kitkat"). The following were issues I found with Android 5.0 ("Lollipop"):
* fdroid repos don't work, which is annoying (https://gitlab.com/fdroid/fdroidclient/issues/111)
* some Activesync servers don't work—I've only seen this reported with Horde (and I had the issue with both 5.0 and 5.2; https://bugs.horde.org/ticket/13702)

Back on CM-11, using the ART runtime, Firefox Sync (Weave/"Deprecated") also fails, apparently with a Unicode string error. It works fine with Dalvik. I don't know if this would have been an issue on Lollipop as well which uses ART by default. I didn't look for a specific bug for this, but was surprised that this sync was still supported since it was supposed to go away several versions ago (https://bugs.horde.org/ticket/13702). Apparently work on making the new service easy to use by third parties is either hard or just not a priority—the whole issue seems to have been bungled and now everyone's stuck with a mess. (https://bugzilla.mozilla.org/show_bug.cgi?id=989756#c14)

I also missed some of the UI elements from CM-11, like the circular battery indicator (is this a theme added by CM?) The settings menu was also more usable on CM-11. In general, Lollipop seemed to waste space, although I had mixed feelings about the task switching interface (it did seem to show more options at once, but made the active surface a bit small on a phone screen). A lot of Lollipop was flat, and Apple-like, looking pretty without giving the user any indication of whether interfaces were scrollable or otherwise how to interact with the device.

Unlike other reports, I did not run into any issues with WiFi or battery life on Lollipop—in fact, both seemed to be at least as good if not more reliable than on CM-11 and CM-10.2 but I don't have any objective tests for that. Specifically, I thnk my worst battery behaviour was in part to K9 synching my mail, and I haven't set that back up.

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.