Karoshi Ethos

It appears that Safari 5 will not respect the base href tag when used in a page served via https when the base href indicates a URL with the http protocol. There is probably more to this issue, but I ran across it while working on an Authorize.net integration using their SIM API. After a successful transaction, Authorize.net requests a URL of the developer's choosing, and proxies the response through their server to the user's browser. This allows developers to do callback processing of the successful transaction on their server, and display a custom "thank you" page. Brilliant. The problem is, if you have any included CSS, JavaScript, or images in the page, you either need to give them all fully qualified URLs, or use the base tag to specify a root URL to use for all relative link attributes in the page (href, src, action, etc.). I've done this same type of integration many times, going back about six years, and have never had a problem using the base href in this scenario. Now, Safari 5 will completely ignore the base href and display a big mess of un-styled markup when you reach the end of the Authorize.net transaction flow.

I do a lot of work with the Smarty template engine, and the site I'm working on now is large, complex, and has a fairly advanced layout with lots of CSS and jQuery goodies. Everything is so abstracted, it's just not practical to construct a single template for my Authorize.net relay pages, of which there are several. It's also not practical to change the templates to use fully qualified URLs for everything. So what I did was write a simple Smarty modifier that prepends a specified URL to all of the relative src, href, and action attributes within the supplied string. It also fixes background: url() inline CSS styles. On my relay templates, all I have to do is wrap the contents of the template in a {capture} function, assign the output to a variable, and run it through my modifier. Absolute paths for all. Here's the modifier code, hopefully it will save someone a few grey hairs.

<?php
/**
 * Smarty plugin
 * @package Smarty
 * @subpackage plugins
 */

/**
 * Smarty base_href modifier plugin
 *
 * Type:     modifier<br>
 * Name:     base_href<br>
 * Purpose:  apply a base URL to all relative
 *				src, href, and background:url() attributes in a string
 * @author   Rob Ruchte <rob care of thirdpartylabs com>
 * @param string
 * @param string
 * @return string
 */
function smarty_modifier_base_href($string, $base_href)
{
	$base_href = (substr($base_href, -1)!='/') ? $base_href.'/':$base_href;

	$patterns = array();
	$patterns[] = '/href=\"[^#]\/?([^\"]*)\"/i';
	$patterns[] = '/src=\"\/?([^\"]*)\"/i';
	$patterns[] = '/action=\"\/?([^\"]*)\"/i';
	$patterns[] = '/background: ?url\(\'?\/?([^\'|\)]*)\'?\)/i';
	$patterns[] = '/background-image: ?url\(\'?\/?([^\'|\)]*)\'?\)/i';

	$replacements = array();
	$replacements[] = 'href="'.$base_href.'$1"';
	$replacements[] = 'src="'.$base_href.'$1"';
	$replacements[] = 'action="'.$base_href.'$1"';
	$replacements[] = 'background: url(\''.$base_href.'$1\')';
	$replacements[] = 'background-image: url(\''.$base_href.'$1\')';

    return preg_replace($patterns, $replacements, $string);
}

/* vim: set expandtab: */

?>

Usage:

{capture assign=output}
{include file="include/header.tpl" title="Event Ticket Registration"}
	<div class="span-3" id="leftbar">
		[...]
	</div>
	<div class="span-11 last" id="content">
		<div style="background: url(/images/feature.jpg);">
			[...]
		</div>
		<div class="span-11 last" id="copy">
		<div id="breadcrumbs">
			{foreach from=$breadcrumbs item=currNav name=breadcrumbs}
				{if !$smarty.foreach.breadcrumbs.last}<a href="{$currNav.path}">{/if}
				{$currNav.title}
				{if !$smarty.foreach.breadcrumbs.last}</a>&nbsp;&raquo;&nbsp;{/if}
			{/foreach}
		</div>
        <h2>Registration: {$event->getTitle()|escape}</h2>
	    {$purchaseSuccess}
        </div>
    </div>
{include file="include/footer.tpl"}
{/capture}
{$output|base_href:$smarty.const.BASE_URL}

Recently, Blogger began appending a tracking gif to the content of each entry in their Atom feeds. The URL used in the image src uses https, most likely to avoid warnings when it's rendered in a https context. For some reason, when rendering the feed content containing the tracking image, the Flash player can crash, taking the browser with it on certain platform/browser combinations. We found the problem in FireFox 3.0 on OSX, but only on PPC Macs. Go figure.

In our case, we are proxying the Atom feed through a PHP script so we can display the feed contents to user agents without the Flash player. This made it fairly easy to iterate through the entries, and with a simple bit of regex, strip out the offending markup from the contents.

Blogger is wrapping the image tag in a div with a very specific CSS class, which makes our job easy:

Depending on what you're using to parse the feed, you may or may not need to be concerned about decoding and encoding html entities during this process.

I just ran across a really annoying problem with Thickbox after upgrading from jQuery 1.3.1 to 1.3.2. The gallery functionality in Thickbox broke after the upgrade - instead of opening with the first image, the loading animation displayed forever without loading any content at all.

Turns out, the @ selector syntax was deprecated in jQuery 1.3, and was removed in 1.3.2. Simply removing the single occurrence of the @ character in the Thickbox js solved the problem.

I decided I'd try an FLA-less project using embedded library assets from swfs, but that proved contrary to my workflow. If I'm going to use the IDE for layout, then I've got a good handful of layers. Not just a graphic or three. I want several things to align, you know visually, so I used a visual layout tool to configure my layout. Smart, huh? But you can't pull in an entire timeline worth of assets and then provide the class and still expect to get the whole thing wired up. Flex compiler's gotta be all one child asset at a time within the class.

Despite reading more than once that you could somehow:

[Embed (src="library.swf", symbol="layout"]
public class layoutClass extends Sprite
{
// rest of class here
}


I never got it to work. I only got the directive to work for class property members, not the class definition itself.

You could use composition to pull an entire layout's worth of assets in. But then you've got this magic asset container property that's different from the local "this" context. No, I wanted all the assets linked to the class in one place, like I was used to with the IDE in the first place.

I decided it was worth it to reparent all the assets out of a temporary holder, and reconstruct the layer stack in the new parent.

I knew the code for this wasn't hard or long, but it isn't exactly obvious:

//Layout is a class that can be populated via
//embed directive or by having a 'skin' swc in your classpath. 

var layout:Sprite = new Layout()

var len = layout.numChildren
for (var i=0; i<len ; i++) {
  //move the child into this
  var c = addChild (layout.getChildAt(0))
  //link the property name of the class to the asset
  this[c.name] = c
}


Merry WhateverDecemberweenNewYear.

(see the original Mangled Kerning post)

We decided when we started this blog it wasn't going to be a bunch of whine, whine, whine such-and-such doesn't work. If we couldn't find a workaround of some sort, then we were just polluting the search space with more of the same "anyone else have an answer?" You may have dug through some of that to get here. There's value in seeing you're not the only one out there, but it's so limited we decided to avoid it if at all possible.

So. You've got an autosized textfield. You want to use Anti-alias for readability. But you've noticed strange spacing problems around HTML anchors. You've got a few options. I've come back to edit this post several times after seeing opportunities to achieve the same fix with less effort, but I'm preserving some of the more complex work-arounds because the bug is so quirky, someone might have need to try one of the uglier approaches.

1) After setting the htmlText, access the height property of the field, then it's safe to turn off autoSize which will allow correct kerning behavior:

var temp1 = (field.height)
field.autoSize = TextFieldAutoSize.NONE

You won't have to wait additional frames or anything like that. Just remember to turn autoSize back on before changing the text.

2) Set the antiAliasType property of the TextField to flash.text.AntiAliasType.ADVANCED after the field has already been on the stage for at least two (count 'em: 2) frames. That's frame 3 if you're following along at home and your TextField was present on frame 1. Use the visible property to avoid epileptic seizures.

3) It would appear that only authoring-tool-placed TextFields require the extra 2 frames. Create a TextField from code, and you can set the antiAliasType property of the TextField to flash.text.AntiAliasType.ADVANCED in the next frame. Again, use the visible property to hide the layout jump:

var field = new TextField( 20, 20, 500, 1)
addChild(field)

field.embedFonts = true
field.multiline = true
field.wordWrap = true
field.autoSize = TextFieldAutoSize.LEFT

var styles = new StyleSheet();
styles.setStyle("p", {fontFamily: "HelveticaNeueLT Std Med Cn", fontSize: "18", kerning: false, letterSpacing: 0, color: '#CCCCCC'})
styles.setStyle("a", {textDecoration: 'underline', kerning: false, letterSpacing: 0, color: '#FFFFFF'} );
field.styleSheet = styles

field.htmlText = "<p>This top line is necessary to push the content down because that matters somehow in this simple example of <a href=\"http://nowhere.com\">Quirky</a> text in Flash.</p>"

//NEXT FRAME:
field.antiAliasType = flash.text.AntiAliasType.ADVANCED

4) If you must be a sadist, use a hybrid approach to replace authoring tool-placed TextFields with runtime-created TextFields while preserving position, dimensions, autoSizing, styles, etc. And after you've gone to all the trouble, don't forget to set the antiAliasType to advanced. If you're willing to let the original field handle the autoSizing, you can turn off autoSize on the dynamic field, size it according to the first field, and avoid having to wait a frame to set the antiAliasType as in #2. Just remember that if you need to change the field's contents, you'll have to turn autoSize back on. NOTE: Your mileage may vary, but I found that wordwrap was uneffected by this bug, so even though the kerning sometimes jumps around aggressively, I didn't find any changes in wordwrapping, thus no changes in sizing to worry about ... so far.

One of my partners just informed me that Microsoft's Windows Mail that currently ships with Vista suffers from the same URI encoding issues that I discussed in a previous post.

"I have just discovered that the MS Mail client on Vista has the same problem as Apple Mail, when it comes to handling urls that include a "hash" component.  The hash-sign gets url encoded before it is sent out to the browser, and so the browser thinks it's part of the url and sends it on to the server, rather than treating it as a hash.

I sent someone a link to the [***] stuff I did, and it got busted by their mail -- When I finally figured out what was happening, I had to pause briefly and confirm that they weren't using a Mac.

It's so simple it kills me... and MS and Apple are both supposed have the best minds in the world working on this stuff !?

If you ask me, this is pretty good proof that Vista is heavily based on on OSX (conceptually, that is).  I mean... they've even copied the bugs!"

Work long enough with Flash and dynamic textfields, and you'll probably run into this one—words that appear to have an extra and/or missing space preceding or following them, often when a link is introduced via the <A> tag. It doesn't happen with every font (I was using Helvetica Condensed—other condensed fonts seemed faulty as well), it doesn't happen with every link (certain letter combinations have a high degree of reproducability, others no problem).

I spent half a day narrowing it down. Since my text was originating from XML, it first masqueraded as some sort of entity or character encoding problem. I messed with TextFormat and StyleSheet (mutually exclusive by-the-way). A later wild goose test-case showed that flipping the autosize flag off made the issue disappear. Fine, but I need autosizing.

When Andreas Heim pointed out the solution, I remembered I'd run into this before: "Do you happen to be using 'Anti-alias for readability?'" Sure enough, flip it to "Anti-alias for animation" and all's well with the world.

I can only hope that the Flash 10 player addresses this bug. With all the work that's gone into its type rendering features in this revision, I'd certainly assume so. I'll post some test cases / screenshots in the next update.

Download example FLA & SWF

Update: Screenshot of effected swf. Verified broken in Flash 10 beta player.

OK, so browsers are not supposed to send named anchors (or anything after them) to the server. However, I noticed today that SWFAddress links like this:

http://example.com/#/portfolio/myClient/myProject

...when sent as plain text via email to an iPhone, get URL encoded when displayed in the mail client, so Safari receives the URL from Mail like this:

http://example.com/%23/portfolio/myClient/myProject

...and happily sends the whole URI to the server, which looks for something to do with a path containing %23, and comes up with a 404.

This is a clear violation of URI RFC 3986, which states:

2.2. Reserved Characters

URIs include components and subcomponents that are delimited by characters in the "reserved" set. These characters are called "reserved" because they may (or may not) be defined as delimiters by the generic syntax, by each scheme-specific syntax, or by the implementation-specific syntax of a URI's dereferencing algorithm. If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed.

reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"

/ "*" / "+" / "," / ";" / "="

The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications. Thus, characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI

Furthermore:

2.4. When to Encode or Decode

Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form.

In other words, keep your dirty mitts off of my URI's!

I spent some time poking around in Apple Mail (full OS X version, not on the iPhone), and noticed that the Edit/Link/Add dialog does not allow named anchors in URLs! As soon as you enter a # in the dialog, the "OK" button is disabled.

So clearly Apple is aware of the problem, but have yet to give us a good solution. This got me even more curious - I wanted to see how the iWork apps handle anchors. Turns out that Pages, Numbers, and Keynote '08 all encode anchors in URLs added via the hyperlink dialog! This means that we have a bigger problem than just the iPhone edge case, any links in documents produced using the iWork suite can potentially be malformed. For sites that make heavy use of SWFAddress, this is a huge problem.

I fired up MS Word 2004 for Mac, and was pleasantly surprised, it has a fairly robust interface for working with links that contain named anchors, which results in properly formed URLs.

So what can we do about this? On the server side, we can use mod_rewrite to trap incoming URIs that contain %23 (or an actual # if it comes in, even though it shouldn't), and basically redirect it right back to the client unencoded, so the browser can call the proper URI, and handle the named anchor appropriately.
RewriteCond %{REQUEST_URI} ^(.*)?#(.*) RewriteRule .+ %1#%2 [NE,R=301,L]
The problem with that shotgun approach is that it will trigger the redirect for URIs that rightfully contain URL encoded hash marks. Consider this; your app displays news posts, and pulls the post data from the server using nice semantic URLs, like http://example.com/news/My+Post+Title. The first time you have a post with a title like "We are #1", you will be unable to access the data, as the server will receive a request for http://example.com/news/Were+are+%231, and send a redirect back to the browser to http://example.com/news/Were+are+#1, at which point your browser will fire off a new request for http://example.com/news/Were+are+, which will result in a 404. This will not do.

For browser based client apps that implement SWFAddress, we need a more surgical approach to detecting and redirecting URLs with bogus encoded anchor delimiters.

Here are some mod_rewrite rules for making this happen (mod_rewrite docs can be found here):
RewriteRule ^#(.*) /#$1 [NE,R=301,L]
If your client app loads at the site root, and is only accessible from /, here is a simple solution. This traps and redirects URLs like http://mydomain.com/%23/some/stuff to http://mydomain.com/#/some/stuff
RewriteRule ^path/to/my/app/loadpage.html#(.*)
↵ /path/to/my/app/loadpage.html#$1 [NE,R=301,L]
If your app is further down in the site structure, you can include the path to it, perhaps including an HTML page that loads it, if appropriate. http://mydomain.com/path/to/my/app/loadpage.html/%23/some/stuff to http://mydomain.com/path/to/my/app/loadpage.html/#/some/stuff
RewriteRule ^path/to/my/app/(index\.html)?#(.*)
↵ /path/to/my/app/index.html#$2 [NE,R=301,L]

If you're using an index page to load your client app, it may be accessed either by the path to the directory, or the full path including the file name. Putting an optional check for the file name cracks that nut.

Needless to say, this does nothing to help standard named anchors in HTML pages, it's just a band-aid for client apps that use SWFAddress. Apple really needs to address this issue, and I think it's safe to assume that there are other apps and services out there with the same problem.

UPDATE:
One of my partners just informed me that Microsoft's Windows Mail that currently ships with Vista suffers from these same URI encoding issues!

"I have just discovered that the MS Mail client on Vista has the same problem as Apple Mail, when it comes to handling urls that include a "hash" component.  The hash-sign gets url encoded before it is sent out to the browser, and so the browser thinks it's part of the url and sends it on to the server, rather than treating it as a hash.

I sent someone a link to the *** stuff I did, and it got busted by their mail -- When I finally figured out what was happening, I had to pause briefly and confirm that they weren't using a Mac.

It's so simple it kills me... and MS and Apple are both supposed have the best minds in the world working on this stuff !?

If you ask me, this is pretty good proof that Vista is heavily based on on OSX (conceptually, that is).  I mean... they've even copied the bugs!"