Updating MacPorts

Hopefully the last time I forget this:

  sudo port selfupdate

I've found that this is the most common fix for a failed port install. For example, today, I had the following error when trying to upgrade Subversion:

> sudo port upgrade subversion
--->  Building sqlite3 with target all
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_sqlite3/work/sqlite-3.6.1" && gnumake all " returned error 1
Command output: sh: line 0: cd: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_sqlite3/work/sqlite-3.6.1: No such file or directory

Sometimes a port clean is also required.

Fix for "access denied" problem when submitting background file upload

Since Scoodi started to rise in popularity, we've been getting feedback from some Internet Explorer 6 users saying that their photos weren't being uploaded during the process of creating an item. Scoodi uses a common browser hack feature to achieve uploading files in the "background", similar to adding attachments in GMail, so you can continue to fill in the form while photos are uploading. The trick involves setting the target of the file upload form to a hidden frame, so that when the form is submitted, the result is sent to the hidden frame instead of having whole page re-displayed with the result.

Luckily, we were able to reproduce the problem on one of our test machines (though not on another, which made things more frustrating interesting). The difference ended up being in the security settings, specifically the "allow sub-frames to navigate across different domains" setting.

To make a long story short, our issue was to do with how we were setting the src attribute on the hidden iframe. When we enabled Asset Hosts, our source attribute was an absolute path to one of the asset hosts:

  <iframe ... src="http://asset2.scoodi.com/path/blank.html">

Going back to the security setting, in our case, it was saying you can't submit a form served from www.scoodi.com to a target frame served from asset2.scoodi.com. When the setting was enforced, it raised an "access denied" error from the line of JavaScript that submits the form.

Once we worked out the problem, the fix was simple: make sure the iframe src attribute uses the same domain as the page source. In our case, it was as easy as using a path relative to the server:

  <iframe ... src="/path/blank.html">

It was no coincidence that the bug appeared with the increasing number of users to the site, though it wasn't because we were getting a wider range of browsers and configuration permutations. We enabled Asset Hosts because of the increase in users, and when we did that, those IE6 browsers with higher security settings stopped working.