I’ve been talking with Philipp Lenssen from the excellent Google Blogoscoped, and he had some great feedback. In particular he called out the problems with some things not showing up correctly in the preview window.

This is something I noticed too, and have a bug filed in sourceforge’s bug tracker on, but it hadn’t made it to the top of my list.

I spent a bit of time on it this morning, and managed to greatly improve it. First off, I was changing the HTML to all lower case as part of my security measures, which messed up any case-sensitive resource paths. I’m doing all my search and replace case insensitively now, so I was able to remove that.

I also discovered that the BASE tag I was adding to resolve relative resources should actually point to the full URL of the page. I was trying to be too clever, and setting it to the URL up until the last /, assuming it had to be a folder name. Just setting it to the full URL made a lot more pages show up correctly.

There’s still some pages that have problems so I’m leaving the bug open, but these two changes seem to have fixed most of the issue.

Philipp also asked why I don’t just set the URL of the frame, rather than writing in the HTML into a local one. That’s a good question, since the current functionality would still work. I’m planning on adding something to help find search terms in the page in the future though, highlighting and scrolling to the right words, and that wouldn’t be possible just setting the location. I like to make life difficult for myself!

I’ve made some cosmetic changes to SearchMash, so that you don’t just see a blank screen while it’s loading. You now see “Loading…” in the results frame, and a quick primer on how to use SearchMash in the preview. The primer is there because I had a lot of feedback that the initial screen was confusing to first-time users, since it’s just the google start page in a frame. Hopefully the extra information should make it easier to get started.

I also worked on the problem with the preview window sometimes causing script errors in IE, filed as Preview window can stop working after changing pages and Previewing missing sites on IE stops window in Sourceforge’s bug tracker. I added a try/catch around the access to the preview frame’s document, and tried to reset security by setting it back to the original local ‘src’ if there was an exception. I still see the exception occuring (I’m using MS’s very handy script debugger, which I’ll cover soon), but I haven’t been able to reproduce the problem with the window getting stuck, I hope my changes will unwedge it if it’s in that state.

One of the design goals of SearchMash was to work in a lot of different browsers, which is why I tried to avoid using browser-specific technology.

Both the LiveConnect technology that allows Java and JavaScript to call each other, and the Javascript document object model (DOM) that I use to edit HTML in a page, are well supported by the major browsers. The biggest hurdle is having a recent version of Java installed. I’ve seen figures of around 80-90% of desktops having some version of Java, but I haven’t seen a break-down by version, I suspect many of those are 1.1, which is why I hope to back-port MashProxy to that version. It’s a respectable deployment, but not as high as Flash (I’ve seen 98% figures for some version of that).

My main development platform is OS X, so Safari and Firefox get the most testing, and SearchMash works without problems on both. I’ve also tried some of the other Mac browsers, such as Opera or IE 5.1, but these are not widely used, so I haven’t spent the time to ensure SearchMash works on them. I did hit some quirks in Safari’s LiveConnect implementation, since Java strings don’t seem to be converted to JavaScript ones when they’re passed back to the script, but stay as wrapped Java objects. This means you can call Java string functions on them from the script, but JavaScript functions don’t work. Since there’s some overlap in JavaScript and Java’s string functions, it took me a while to figure out what was happening, but once I did, I was able to force a conversion by creating a new JavaScript string variable from the one that was passed back.

Since most of the world uses a PC, making sure that SearchMash works on Firefox and Internet Explorer was a priority. I only have one machine with Windows XP available, but I’ve been able to make sure it runs on IE 6 and 7, and on Firefox 1.5.

I’ve found IE’s Java to JavaScript connection to be a bit more picky than the other browsers. I’ve just found a bug that can cause the applet to crash when I change pages in IE for example, it looks like using an out-of-date JavaScript DOM object can cause a security exception.

I’ve done no Linux testing, because I don’t have a system set up to run it. I didn’t hit any big differences between Firefox on the Mac and Windows, so I’m hopeful it will just work on Linux/Firefox too.

Supported Browsers

• Internet Explorer 6.0 (Windows)
• Internet Explorer 7.0 (Windows)
• Safari 2.0 (OS X)
• Firefox 1.5 (Windows and OS X)

Untested

• Internet Explorer 5.0 (Windows)
• Opera (Windows)
• Netscape
• No Linux testing has been done

Tested, but not working

• Internet Explorer 5.1 (OS X)
• Opera (OS X)