BulkDump

You do hate when you get very obscure error reports from your clients? Atleast I do. Especially those screenshots of the very descriptive Microsoft “This program has encountered error and needs to be closed.”. Why the default crash dialog needs to be so general and all the interesting bits are hidden behind some “click here” link? Normal users usually just take screenshots of the first error dialog they see and assume we would know from that what’s wrong.

This time the problem was that IE was crashing instantly when visiting our web application’s first page. I asked our client to send some screenshots of his IE settings and I google around a bit. I instructed him to disable 3rd party extensions which did solve the problem. Further investigation revealed that the problem was Textware’s QuickFIND BHO which he no doubt gotten from Cambridge Learner’s Dictionary. I could find only one screenshot of this program in action. Looks quite useful application, but definetely very buggy. Unfortunately the Textware company is long gone as well. Their website just points to some very generic site. I doubt we will be getting any updates to QuickFIND.

The problem is the way this IE add-on works. It monitors your mouse movements in IE and displays info about the text your mouse is hovering. For some reason prototype.js makes the plugin to crash and take IE down with it. I really hope we don’t have to try to solve this issue, or are forced to strip prototype.js till it’s working. And to be honest, it would only solve the problems in our website. There are many Web2.0 applications in the web, and especially since Ruby on Rails relies heavily on the prototype.js and includes it by default, these QuickFIND users are going to experience more and more IE crashes. Even IE7 crashes just like that.

If we have to go down the harder road, I will definitely report back my success in debugging prototype.js. Right now, we’re waiting on customer’s opinion and hoping for the best.

I could find only couple of sources of the same problem:
Source 1,
Source 2

Coffee break at work and I thought I could share some experience with Ruby on Rails to_json while consuming the liquids. My collegue experienced problem with following kind of code:

update_page do |page|
    page.replace_html('content_div', :partial => 'content')
end

There’s nothing special in this code, except the fact that our partial returns javascript to update other elements (in this case it was few buttons which were within the partial itself). The problem is that the replace_html renders the partial into a string, which in return gets transformed into javascript string argument with Rails’ String.to_json and that method does not perform correct escaping when the string contains </script> tag.

Even though such tag normally wouldn’t need escaping the problem appears within the browser. I’m sure there are differences in browsers, but we are using Firefox which intepretes the literal </script> within the javascript string as being the end of the script block. That results incorrect behavior for evaluating (or infact not doing any evaluating of remaining) javascript.

We could have moved the javascript separate from the partial, but it would break a lot of other code and make things less easy to manage when the context specific javascript would need to be outputted separately from the partial. Instead my collegue and I did some XP programming and dug up how the to_json works and implemented replacement for the to_json to do correct escaping for browser’s parser. Here’s the code we inserted into our enviroment.rb file (that’s the place at the moment we keep our class extensions):

class String
    alias original_to_json to_json
    def to_json
        original_to_json.gsub('</script>', '\<\/script>')
    end
end

It’s a pretty simple piece of code calling the original to_json and doing additional escaping for the script tag. After booting mongrel, everything worked as it was supposed to work. This is something I could really see to be fixed within the Ruby on Rails core itself because such flaw in escaping could easily open security holes for javascript injection hacks and it doesn’t break anything as being just javascript string escaping.