I was working to correct a bug in BlogCFC mobile. The bug happened when a user clicked on a link in an email notification they would get redirected to a blank screen. This would only happen when clicking on a link that was to a specific comment. My initial thought that the redirect link was being generated wrong because of the hash. This was not true, it was generated correctly.

For example, if this was the link to the post


it would be redirected to the following if a user was on a mobile device


This worked just fine. User would be taken to the correct post as expected. However, if the link was to a comment it would look like this:


Then redirect to this:


This redirect is where it was broke. First off, as you can see, there are two hash tags in the url. Secondly, nowhere in the redirect code is there anything to add the original hash to the comment. I know that because of how the mobile version works; linking directly to the comment won't work.

view plain print about
1<cfif isClientMobile()>
2    <!---Mobile Redirect--->
3    <cfset urlVars= listFirst(reReplaceNoCase(trim(cgi.path_info), '.+\.cfm/? *', ''), "##")>
5    <cfif listlen(urlVars, '/') LTE 1> <!---NOT AN SES URL--->
6        <cfset urlVars = ''>
7    </cfif>    
8    <cfset path = cgi.http_host & ListDeleteAt(cgi.script_name, listLen(cgi.script_name, "/"), "/")>
9    <cfif NOT right(path, 6) EQ "mobile">
10        <cflocation url="http://#path#/mobile/index.cfm#urlVars#" addToken="false">
11    </cfif>

I was using cflocation to perform the redirect so the extra hash puzzled me even further. I would not have expected the original hash to be there. After a ton of digging, I stumbled across something. The hash was being maintained and added to the redirect by the browser. A quick search on the net produced a few articles that discussed this very issue. The hash is never passed to the server. So, looking at the cgi scope or any other scope would never produce the hash or even elude to the fact that there was one there.

Now, after reading all this I understood what was happening. The extra hash was tripping up jQuery Mobile. It was trying to load a non-existent page. So, what I had to do was remove the hash to the comment from the url.

I tried a bunch of different things. But, as long as I was using cflocation I would never get around it. I had to do the redirect client side. Normally, I am not opposed to this. However, mobile is different. I now have to rely on a mobile browser. Something that can be unreliable for many reasons.

I first tried to do the redirect with JavaScript. This worked just fine. I just did a window.location and the user was redirected to mobile and the original hash was gone. I also tried doing with a meta tag. This also produced the same result. Now, to choose what to do.

In the end I went with the meta tag. Mostly because it ended up to be less data transfer and faster. I also didn't have to worry about the client processing JavaScript for the redirect.

So, what did I learn? Hash navigation is appended to a cflocation by the browser if relocating to the same domain. A relocation to another domain won't append the hash to the url. A client location change via JS or meta tag will remove the hash.

I hope you learned something from this as well.

Till next time...