Facebook https mixed content warning on IE9

When browsing the web, you might have seen a "mixed content warning" popup show in your browser. They are most of the time poorly worded and their meaning is quite obscure.

What it means is that your are currently browsing a page with both httpand httpscontent. Typically, if your page is httpsbut one of the css, js or image file it contains is requested through http, the warning will pop.

(It's interesting to note here that not all assets are treated equal. Loading a flash movie through httpdoes not trigger the warning).

The IE special case

Now, what's special about IE is that it also trigger the mixed content warning when content is the other way around. If you're serving a page through httpand load assets through https, it will consider it a mixed content too.

In a sense, that's logical, but it needlessly prompt the user with a dialog that block downloading of all httpsassets until confirmed.

The solution is to make sure that all your assets are loaded with the same protocol as the host page. An easy way to do so is to use the // relative protocol url. This will use httpor httpsautomatically based on the page protocol.

And adding Facebook to the mix

A few months ago, Facebook forced all apps to serve content through https. In the meantime, they suggested that all their users browse their website using httpstoo.

Unfortunatly for us, some of our own users had bookmarks in their browsers and Facebook pages referencing our old http://apps.facebook.com/appname/ url. And following that link triggered the dreaded mixed content warning in IE.

When accessing this page, Facebook was loaded in classic httpbut our inner iframe was loaded through https. So far, so good.

The problem came from one of Facebook own javascript SDK included in our app. This script loaded other scripts based on what it needed.

Unfortunatly, it loaded the other scripts from an http(not https) server. The SDK has two distinct sets of urls, based on the current page protocol.

It was wrongly considering being in an httppage, not an httpsone, and thus used the wrong set of urls. This confusing comes from the fact that it checks the top page protocol instead of checking the current page protocol.

After some googling, I found a solution that consisted in forcing the SDK to consider that we are in httpsmode by calling : FB._https = true before the call toFB.init()

Almost there

If correctly forced FB to use the correct set of urls, thus removing the mixed content warning. And I almost thought it would be that easy.

It was not.

This did not fixed the payment popup. All Facebook UI element loaded correctly (feeds, permissions, requests), but the payment popup.

I couldn't find a way to fix that, so I reverted to a more brutal approach.

Final and brutal solution

All my problems came from the fact that FB thought we were serving httpwhile in fact we were serving https. So the solution, might be to force FB to serve httpsfrom start to end.

I wanted to detect if the page was loaded through http://apps.facebook.com/appname/ or https://apps.facebook.com/appname/.

Unfortunatly, due to cross domain restrictions in Javascript, we are not able to read, from inside and iframe, the parent frame properties. So I couldn't read top.location.protocol to easily check if I needed to redirect.

But, as I mentionned earlier, FB._https incorrectly report that we are not in httpsbecause it checks the top protocol. So I used this var, to know if the parent frame was in the correct protocol or not. Using this own FB bug to fix itself.

Now, for the redirect : even if I couldn't read thetop.location, I could modify it. I just had to call top.location.url = 'https://apps.facebook.com/appname/' to redirect the whole page.

I hardcoded the app url because there was no way to get it from js, and I took care of keeping any GET parameter passed before the redirect, and I ended up with this :

if (!FB._https) {
  var appUrl = 'https://apps.facebook.com/appname/';
  var iframeUrl = location.protocol+'//'+location.host+location.pathname;
  var redirectUrl = location.href.replace(iframeUrl, appUrl);
  top.location.href = redirectUrl;
  return;
}
FB.init(options);

Conclusion

I'm not really proud of this solution, as it is mostly a hack and will force a useless loading of the http version before loading the https one, but that's the best I've found. If any of you have a better solution, feel free to comment.

PHP AND / OR differences with && / ||

Just found this weird little behavior of PHP today :

<?php
$a = false;
$b = true;
$c = $a OR $b;
$d = ($a OR $b);
var_dump(compact('a', 'b', 'c', 'd'));
?>
array(4) {
  ["a"]=>    bool(false)
  ["b"]=>    bool(true)
  ["c"]=>    bool(false)
  ["d"]=>    bool(true)
}

$a OR $b in fact returns $a, while ($a OR $b) returns the result of the parenthesis. On the other hand, $a || $b correctly returns the result of the expression.

It seems that ANDand ORare weak compared to && and ||.

Be aware of that, or it might backfire on you. Or just discard all AND/ ORin favor of && /||

Weird PHP behavior when casting as an object

I've just stumbled upon that weird behavior when force casting the return of a function to an object. The PHP result was not what I expected.

$a = null;
echo empty($a) ? "Yes, I'm empty" : "You should not see this"

This is pretty straighforward code. Now, we test it with an object.

$a = (object) null;
echo empty($a) ? "Yes, I'm empty" : "You should not see this but, actually, you do."

Note that it even gets weirder when (object) false and (object) true become objects with a key scalar, set to false

This is one of the little things that make me want to ditch PHP for a better language.

Web and dev events in Paris

For the past month or so, I've attended quite a bunch of dev and web events, here in Paris.

Every time I get back from one, I wanted to post something about it. But I never did, as I always seems to have something more important to do. That's quite a shame, because those events were (for the most part) really interesting, some were even really motivating.

So, expect a full blog post on each of them in the coming days. For the time being, here is just an overview.

Paris Web is THE french web event. Two days of conferences about the web, not too technical, but very practical. Here we speak equally about the "why" than about the "how". Very great speakers, team and place. The third day is for workshops, in smaller groups.

Then comes Paris JS, held each month. It's an evening of informal talks about Javascript, a few speakers will demo an app, a framework, or talk about anything JS related. Very great to meet interesting JS fellows, and exchange about frameworks and projects.

Paris Hacker is an other informal event, where everyone is free to speak about any hacky/geeky subject. Most of the time we review the last Hacker news posts and discuss them, talk about incoming events, and so on. There almost no trolling. Most of the time.

JsGuru is a completly different kind of event. This one is a one-day Javascript formation. It costs real money this time, but you got to learn a few tricks and get your started on some frameworks and libraries like Backbone, Mustache, Lawnchair, etc.

And the final one is the Hack Day Paris. Partially organized by the same team as Paris Hacker, it was a 40hrs hackathon, with no constraint except to "build something brilliant". More than 180 fellow geeks attended, and 43 projects were finally demoed on stage. This was one of the most motivating experience I ever did.

A few days after the Hack Day, an other event was held by SFR were all the Hack Day participants were invited. Along with participant from two other events (Designer Weekend and Museomix), the goal was to help all those people to meet, and to showcase some of SFR latest innovation. This is clearly the event that I liked less.

Paris Web 2011 : Accessibility

In October, I was attending the Paris Web event. For those that haven't heard of it, it is THE french web event, two days of conference on various subjects web related. It is language agnostic and talks range a very broad list of topics from accessibility, open data, security, performance, UX, UI, html5, etc.

I've attended 16 talks in the course of the event, plus a full day of workshops. I would need far more than a single post to write down everything I learn from those days, both technical and human. I really love Paris Web for those moments where you start to chat with other peoples as passionate as you are.

Here, I'll only focus on a specific subject that everyone cared about : Accessibility.

Know your audience

Accessibility was discussed at length, as it always is the case in Paris Web. It is one of the values held by Paris Web that I also hold dear. My only regret is that it feels like everyone in Paris Web attendee were already familiar with it, had implemented at least the basic good practices, that we all were already convinced of why it is good. I kind of feel that were not the right public, that the speech was wasted on us as we already were convinced.

We, as web professional, are aware of the accessibility concerns. Big groups and public websites are aware of it too. But the middle ground of small companies do not care. "This is not our target", "Spending 40% more for 10% of users ? No way", "We are not big enough", are answers I've often heard when trying to explain to clients why I cared about aspects of their projects they didn't even see.

Continuous integration

Laurent Denis and Elie Sloïm told us that accessibility should not be thought as the last part of a project, the one we do the day before launch. It has to be taken into account for the very start of the project, in the conception phase, and not at the end, as a correction phase.

Every person ever included in the project should be at least aware of the accessibility concern, this is not the work of one man alone. Accessibility experts are not people you can hire to fix your website once it's done. They should be requestd during all the conception phase.

No one ever read the 100 page accessibility audit. No one wants to be told at the end of the project that what they did is wrong and that they should start everything over from scratch. Instead, mini briefs, on mini subjects, sometimes no longer than 15mn, on a regular basis can yield very great results. Starting with the general website semantic, adding unobstrusive javascript, and going deeper and deeper into tasks more and more difficult.

There is no perfection in accessibility. There's only an ideal we tend to. You don't fix a website for accessibility, you just improve it.

Throw away formal accreditations

We can't make a website absolutly perfect, we can just improve it on little touches to make it better and better. A, AA and AAA homologation is absurd, because there is no metrics to quantify the level of accessibility of a website. How could you compare two accessibility features ? How video subtitles is more accessible than alt on images ? We should just forget the accreditations. At first, we did accessibility improvement to help people with disabilities. Somewhere along the years, we became legally forced to provide accessibility measures and it became one more line on the planning and we lost the initial meaning that was driving us.

We should really take accessibility down that pedestal we put it. It's not that hard to make an accessible website, don't be scared by the list of accreditation and rules.

What about HTML5 ?

The geek side of your mind can't stop feeling the excitation when everyone talks about all the shiny stuff : file API, history, geolocation, web sockets, forms, etc. But the eternal question remains : what good are those new toys if we can only serve them to a handful of users. Will I use them now, for the benefit of only some, or will I wait for better support for the benefit of all ? But if I don't promote them myself, I'm only slowing down adoption by all browsers...

That's a tricky question and I don't have a definite answer (and that's fine !).

Paul Bakaus posted recently and article where he stated that it is better to build something awesome for 70% of the people that something good for 95% of them. It surely is true in the gaming world where gamers have the habit of buying new hardware to keep with the new game graphics. In the classical web world, we are still scared of asking the user to change its browser.

But it tickles my accessibility sense when someone told me that a part of the users won't be able to access the content because they don't have the correct requirement. This feels absolutly contrary to the open web principles.