Pixelastic

You can clip our wings but we will always remember what it was like to fly.

Posts tagged with "chrome"

SWF caching issues accross browsers

Here are some quick notes on various browser caching behavior. I was fiddling with Wireshark to optimise my caching strategy and found some quirks one should be aware of.

First, let's define some reload vocabulary.

  • initial load is the first time the page is loaded, when the cache is empty.
  • hard reload is the classical reload. Clicking the Reload icon, or pressing Ctrl+R / F5.
  • link reload is when the page is loaded again after you click on a link to it
  • soft reload will be loading the page again by pressing enter in the address bar
  • navigational reload is the reloading of a page that occurs while using the previous/next buttons.

For the rest of this blog post, we will assume an HTML page loading the same .jpg file multiple times and the same swf file multiple times too (we will use both IE specific and general swf markup).

The html itself is not cached.

Also, all those static assets will have a Cache-Control:max-age=29030400 header.

All the network tests have been made using Wireshark.

Chrome

Initial load : Download of jpg and swf once each. Perfect.

Link reload & navigational reload: Nor jpg nor swf is loaded again. Perfect.

Soft reload & hard reload : The jpg is downloaded again but not the swf. Chrome sends a Cache-Control:max-age=0 header to the jpg request, to force loading it again.

Reloading images is a standard behavior on images, but I wouldn't have expected it on soft reloads.

Safari 5 Win

Safari behaves much like Chrome, with one important difference. It does not cache swf files at all.

Initial load : The jpg gets downloaded perfectly, but the swf gets downloaded multiple times, one per instance.

Link reload & navigational reload : The jpg is correctly fetched from cache, but the swf are all downloaded again. No swf is ever cached.

Soft reload & hard reload : Much as Chrome, Safari forces the reload of the jpg here. As you might guess, it also reload all the swf too, multiple times.

It means that Safari 5 does not cache any swf file at all. That's pretty impressive.

This same caching bug is talked about on this other blog. I've also tried including flash files from within another flash file (much like the Satay method). The results are the same : no swf flash is ever cached, even in the same html request.

It is supposed to have been fixed in Safari Mac (anyone can confirm this? I don't own a Mac) but the issue is still here on Safari Windows.

IE6, IE7 and IE8

IE6, IE7 and IE8 behaves the same here. They have a less severe version of the bug than Safari 5. At the time of writing I didn't have IE9 to test on it.

Initial load : Same bug as Safari here. The swf are downloaded multiple times, once for each instance. The jpg is only download once.

Link reload, navigational reload and soft reload : This time, everything is fetched from the cache. Actually, even the html is seems fetched from cache (I didn't investigate that much)

Hard reload : Html and jpg are fetched from the server, swf file stays in the cache.

It appears that (surprisingly) IE behaves quite well. Its caching behavior is more aggressive than the others (soft reload is really soft). However, it still have a nasty side effect of loading swf files multiple times on the same page. Shouldn't happen a lot in the real world, but still nice to know.

Firefox 4.0

Initial load : No issue arising. It does fetch each resource once.

Link reload, navigational reload and soft reload : Fetches everything from cache, nice.

Hard reload : Re-request jpg and swf files by adding a Cache-Control: max-age=0 request header. This feels like the expected behavior.

 


Losing session on each request with cakePHP and Chrome

I finally found solution for one of the more tenacious bug I ever encountered. Share the joy !

I had a website working perfectly under Firefox but when browsing using Chrome, I noticed that my Session gets regenerated on each page load. Constantly. Creating hundred and hundred of useless session files.

And only with Chrome.

Since when using a browser should change the server behavior ? Well I don't exactly know what Chrome is doing with the referer but it seems that it is altering it in some ways.

And cakePHP forces the setting of session.referer_check to true, thus checking that multiple requests with the same PHPSESSID comes from the same url.

As one posted on php.net :

If you have a value specified for session.referer_check you may run into difficulty when someone accesses your site and attempts to log in with a mis-capitalized URL.  The logon will fail because any calls to session_start() will result in the existing session being trashed and a new one being created.  This becomes a bigger problem when the logon is followed by a header("Location: ...") redirect, because the session_start() at the top of the page will fail.

Those two settings combined, and you got a hell of a mess. I first found a quick fix by forcing the setting of session_start() in app/webroot/index.php. But after more reading and debugging I finally found the culprit.

Hacking your way through the fix

There is no easy way to prevent cake from setting this setting, but you can define your own session handler in the Session.save configure key.

Just create file named session_custom.php in app/config/ and set Configure::write('Session.save', 'session_custom'); in your core.php file.

And in that file, just drop the following lines (copy/paste from cake_session.php)

ini_set('session.referer_check', '');                    // Killing this f***ing config that was causing so much trouble with Chrome
ini_set('session.use_trans_sid', 0);                    // No session id in url
ini_set('session.name', Configure::read('Session.cookie'));    // Using custom cookie name instead of PHPSESSID
ini_set('session.cookie_lifetime', $this->cookieLifeTime);    // Cookie like time, depending on security level
ini_set('session.cookie_path', $this->path);                // Cookie path

 

The blockquote cite attribute

The HTML blockquote element can accept a cite attribute that is supposed to hold the value of the source URI of the quote.

Browsers behave differently when getting this attribute in javascript. Opera and Firefox automatically treat it as a URL, prepending the current domain host if none is defined and encoding special characters.

Safari and Chrome on the other end just return the value as it is present in the HTML.

-webkit-box-shadow inset value

Webkit browsers (Safari and Chrome) have the -webkit-box-shadow property defined to add shadows to elements. Shadow can either be outside the box, or inside it (using the inset parameter).

Unfortunatly, only the latest Webkit nightlies have the inset parameter functionnal, Safari 4 does not.

Chrome does indeed have the inset parameter, but it also have a bug when used in conjunction with the -webkit-border-radius property : the inset shadow is visible "behind" the element where the borders are rounded.

This bug does not occur on Mac, but as I have no way to target a certain OS when writing CSS rules, I decided to remove inset box-shadow for webkit browsers on my actual projects, I may re-insert them later when both issues will be fixed.