unicode
Sunday, December 7 2014
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.
[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.
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.
[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.