What does a webtech addict do when in a Tesla?

Tesla Model S infotainment panelWell, checking out the browser, off course!
I had the opportunity to ride along with a friend in his brand new Tesla yesterday. Great ride, but you know that already, so I checked out the browser and data connectivity obviously. I visited my own little “ip check” page and saw this in the logfile:

188.207.103.140 – – [05/Feb/2015:12:17:24 +0100] “GET /check_ip.php HTTP/1.1” 200 132 “-” “Mozilla/5.0 (X11; Linux) AppleWebKit/534.34 (KHTML, like Gecko) QtCarBrowser Safari/534.34”

Breaking it down:

  • The free mobile data connectivity is provided by KPN (Base) in Belgium (and Holland, probably).
  • As per the useragent the car display runs on Linux (that little OS that could is really everywhere these days)
  • The browser is QtCarBrowser, which would obviously be built with QT and WebKit. Based on the WebKit version, one can deduct that the version of QT uses is 4.8. As such, QTCarBrowser seems very similar to QTWeb and might indeed be based on it. HTML5test.com rates QTWeb with 204/555, but Tesla’s QTCarBrowser result might still be different off couse.
  • The WebKit-version, 534.34, is pretty old and as such dates from mid 2011 (QT 4.8 was released in December 2011). This is close to the version that was used in Safari 5.1 (534.48.3).

I sure hope there are not too many vulnerabilities in those old version of of QT and WebKit, but one does not drive a Tesla to browse the internet, does one? 😉

Fixing Firefox’ LessChromeHD to reclaim lost screen real estate

I had been happily auto-hiding the Firefox navigation bar on my small-screen netbook for a couple of years already, until that add-on (LessChromeHD from the Prospector series) stopped working after having upgraded to Firefox 35. So I started Firefox from the command-line and spotted this error:

addons.xpi WARN Error loading bootstrap.js for lessChrome.HD@prospector.labs.mozilla: TypeError: redeclaration of variable event (resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/frank/.mozilla/firefox/jy6bws91.default/extensions/lessChrome.HD@prospector.labs.mozilla.xpi!/bootstrap.js:226:8)

A quick look at the source code confirmed “event” was declared twice, once on line 210 and a second time on line 226. The fix, obviously, is simple; on lines 226-228 replace all references to “event” with e.g. “shownEvent”;

let shownEvent = document.createEvent("Event");
shownEvent.initEvent("LessChromeShown", true, false);
trigger.dispatchEvent(shownEvent);

You can do this yourself by unzipping “lessChrome.HD@prospector.labs.mozilla.xpi” in your extenstions-folder, editing boostrap.js and updating the xpi. Or you could wait for the Mozillians to update LessChromeHD.

Android Chrome bug when styling unicode character?

symbols CSS weirdness in chrome for androidWhile experimenting with the use of Unicode characters in a small proof of concept, I stumbled upon what I think is a bug in Chrome for Android. Apparently character ☰, which renders as ☰ and which most people consider the “options”-icon, cannot be given a color in Chrome for Android whereas other Unicode characters can.
As you can see when visiting this test-page, the 3 symbols styled correctly (font color white) in most browsers (tested on IE8, FF on W7, Ubuntu and Android, Chrome on W7 and Ubuntu), but the options-symbol is not white on Chrome for Android (at least on my Samsung Galaxy S4).
So, does this qualify as a bug, or did I just mess up? Anyone happens to know a workaround?

Facebook force-feeding Messenger, going mobile web instead

So Facebook wants me to install yet another permissions-greedy app just to read messages? That is so frustrating! So no, don’t think so guys. I’m putting Facebook back into the (slightly) safer sandbox that is the mobile web;
facebook forces users from app to web
So thanks for reminding me why I love my mobile browser that much Facebook!

You gotta love HTML5’s input types and patterns

While working on updates of the admin-screen of Autoptimize, I wanted some checks on the URL a user can enter for a CDN. At first I thought I’d do some jQuery-based validation but then I came accross a page (on StackOverflow I guess) that mentioned the new input types and the use of validation patterns, so now I just have this beauty in place;

<input type="url" pattern="^(https?:)?\/\/([\da-z\.-]+)\.([\da-z\.]{2,6})([\/\w \.-]*)*\/?$" />

And to make sure the user gets a visual indication if the string isn’t a valid URL (according to the regex) there’s this CSS oneliner:

input[type=url]:invalid {color: red; border-color:red;}

The nice thing about this is that it is pretty backwards compatible;

  1. browsers that do not know type=”url” will just consider it type=”text” and can still enforce the pattern (if supported).
  2. browsers who support type=”url” but not the pattern, will do more basic validation.

And for browsers that do not support type=”url” nor patterns, there are multiple polyfills available that force older browsers to comply as well. But who cares about older browsers, right?

Thanks for reminding me about AdBlock Plus Google!

So Google removed AdBlock Plus from the Google Play Android store. That is their prerogative, off course, but it does confirm they’re not the cool technology-centric search engine everyone once thought they were. It’s kind of ironic that in December 2011 AdBlock Plus by default enabled the display of “acceptable” ads, a move that seemed to be an attempt to appease (or please) Google.
But whatever way you look at this, Google’s core business (as is Facebook’s) is displaying ads. Sure they try to do that in an intelligent manner. And sure, they have some cool technologies (App Engine, Android, Chrome, …). But at the end of the day they want us to see and click on ads. That makes Google a media company. But whereas traditional media have -at least the notion- of a wall between their editorial and advertising departments, editorial independence does not seem to exist over at Google.
I don’t like particularly like ads, I don’t like widgets snooping on my web-whereabouts and I definitively don’t like Google’s advertising department dictating what applications the editorial team in charge of Google Play should remove. So today I installed AdBlock Plus on all my devices. Maybe you should too?

Introduction to Adblock Plus

Multi-lingual WordPress the Easy Way

Imagine you run WordPress with English as default language, but some posts are in another language. Dutch, maybe? Up until a couple of months ago, you wouldn’t really notice anything about that setup. Google might be slightly confused, but us bloggers aren’t really into SEO anyhow, no? But with the release Safari 5.1, Firefox 16 and especially Internet Explorer 10, support for CSS Hyphenation became (somewhat) widely available and if your theme (WordPress TwentyTwelve or its performance-optimized 2012.FFWD child theme for example) has support for in the CSS, your hyphenation would yield weird results because of the fact that the browser uses the language attribute in the HTML to decide which dictionary to use.
The solution, if your theme is HTML5, is to add the lang-attribute to the article-tag if you have something to check the language with. In my case I just had to copy TwentyTwelve’s content.php and change line 11 into:

<article id="post-<?php the_ID(); ?>" <?php if (in_category('lang:nl')) { ?>lang="nl" <?php } ?><?php post_class(); ?>>

A real simple hack indeed; I check if the article has category “lang:nl” attached to it (which I already used) and set the language-attribute with the correct value if it does. Hyphenation now works for Dutch blogposts and I guess Google will be happier as well that way?

Do background-images lazy-load with display:none?

So, do background-images lazy-load with display:none? I did a quick test by loading this testpage created by Steve Souders on webpagetest.org. These are the results:

Conclusion: don’t rely on setting display:none on background-images to have them lazy load.

CSP: doing unsafe-inline the Firefox-way

A couple of weeks ago I sobbed because of the lack of support for “unsafe-inline” in Firefox. There’s some Mozillians working on that (for CSS, at least), but given the release-train, that’ll probably only appear around Firefox 19. While perusing CSP-related tickets in Bugzilla however, I came across an interesting comment:

Firefox expects “options inline-script eval-script” instead of “script-src ‘unsafe-inline’ ‘unsafe-eval'” which it should be per spec. Also, Firefox expects “xhr-src” instead of “connect-src”.

Come again? So I can tell Firefox to execute inline script even without support for CSP 1.0 after all? I opened up my development-version of WP DoNotTrack to rework the “proof of concept”-code into this:

function wp_donottrack_csp() {
 global $listmode;
 if ($listmode==="1")
  $whitelist=wp_donottrack_getWhiteList(true);
  $csp="default-src 'self' 'unsafe-inline' ";
  if (is_array($whitelist)) {
   foreach ($whitelist as $white) {
    $csp.=" *.".$white;
   }
  }
 // old-style options inline-script for firefox
 $csp.="; options inline-script;";
 header("X-Content-Security-Policy: " . $csp);
 header("Content-Security-Policy: ". $csp);
 // needed for chrome, but safari 5 (latest version on windows) might be broken?!
 header("X-WebKit-CSP: " . $csp);
 }
}

Based on limited testing, it indeed seems to work great this way. So maybe -if this also turns out to work in IE10 and on Safari for Windows- a next version of WP DoNotTrack can ship with CSP-support after all?