Wayne Pan

Earlier this year, when I was developing the AdMob iPhone Ad Units, I ran into a curious bug involving iFrames and CSS Transforms. I didn’t think anything of the bug at the time other than it just seemed wrong. We abandoned some of our ideas because of this bug so I filed it away and moved on.

Fast forward a few months to the iPhoneDevCamp where I met John Resig for the first time. We chatted a bit about the iPhone and mentioned off hand about the bug I ran across. He, excitedly, wanted to see the bug in action and I whipped up a small demo page and showed him. Later on that day he caught up with me and mentioned that he discovered that it was far more severe than he had originally thought and that he filed a bug against Apple.

That bug has now been fixed in iPhone 2.2 and Resig has a full write up here. (I don’t think Apple would’ve fixed this bug if I had been the one to report it so I’m happy that Resig was able to bring it to their attention.)

There was another bug I ran into regarding iFrames and touch events. Curiously enough, touchevents do not register properly in iFrames. This first test [http://waynepan.com/iphone/] demonstrates that you first must touch the parent document before touching the iFrame for the iFrame to register your touch event. The second test [http://waynepan.com/iphone/touchtest2.html] shows that touch events only register in an iFrame for the top ~100px of the entire page. The problem is best illustrated by visiting those links on your iPhone.

These bugs are not security showstoppers, like the click-jacking bug, but they do prevent web app developers from doing cool things in iFrames. We were originally going to use touch start, change, and end events to cycle through ads or give the user the ability to hide them. Ultimately, it was not possible because the iFrame was not receiving the proper events.

So far these have not been fixed in iPhone 2.2 and I still have bug into Apple for this (radar id: 6089245).

We (AdMob) are exploring Amazon’s new AWS service CloudFront which is a simple CDN. Amazon built this services as a true CDN that people could use instead of using S3 what it wasn’t meant for.

There’s a few things I’ve discovered about CloudFront that bear repeating here. These points are important if you’re attempting to use CloudFront to serve up static portions of your website.

• CloudFront pulls from S3 only if the CF node doesn’t already have a local copy. This means that the only way to push out a new file is to change the filename. (style.v1.css, styles.v2.css, etc.) This means that your framework will have to take advantage of this. Without file versioning you’re at risk of serving stale files from different nodes on CloudFront.
• CloudFront doesn’t automatically detect if a browser accepts gzip encoding. You will have to keep separate versions of gzip files (and upload them pre-gzipped). The easiest way to do this is to keep a separate CNAME, eg static.domain.com and staticu.domain.com (u for uncompressed). Your website will then detect the Accept-Encoding header from the client and serve up the appropriate file. Gzipping could decrease your static content by 75% which not only speeds things up for your users but decrease your CloudFront costs.
• You should set the appropriate headers when uploading content to S3. That means setting a far futures Expires Header and a Cache-Control header. You can read more about these here. There are two GUI programs that allow you to do this, BucketExplorer and jets3t. If you want to write scripts, I would suggest ruby and the AWS::S3 gem.

Here is some ruby code to do what I’ve described above.

require 'rubygems'
require 'aws/s3'
require 'stringio'
require 'zlib'

AWS::S3::Base.establish_connection!(
  :access_key_id => '[key]',
  :secret_access_key => '[key]'
)

strio = StringIO.open('', 'w')
gz = Zlib::GzipWriter.new(strio)
gz.write(open('[file]').read)
gz.close
AWS::S3::S3Object.store('[s3 location]',
                        strio.string,
                        '[s3 bucket]',
                        :access => :public_read,
                        'Content-Encoding' => 'gzip',
                        'Content-Type' => 'application/x-javascript',
                        'Expires' => 'Fri, 16 Nov 2018 22:09:29 GMT') 

You know the green dot on the upper left of all OS X windows? This one: .

I have no clue what it does. I’ve even been afraid to hit it 99% of the time because I have no idea what it’s going to do. I just clicked it for one of my Firefox windows and look what happened:

For all the good things that OS X does well, there’s still so many that it does wrong (see the ironically named “Finder”).