Google Chrome. You know it. It’s that way cool, very fast browser from the folks who gave us all a better way to search. Well, that browser, Chrome, from Google? Sometime around March, 2010, it completely forgot that your desktop exists.
What are you talking about Ben?
Oh, you don’t know this story? Sit back and I’ll get you up to speed.
Back in 2008, Google Chrome was released and quickly became the hottest browser on the web. Throughout 2009, more and more users took a shine to Chrome’s minimal UI and fast execution. Built-in debugging tools made web developers giddy. Life was good. Except for one small issue.
You see, Chrome implemented all the latest web technologies and touted itself as being extremely secure. Which was certainly true, unless you happened to access local file content with the file:// protocol. Then, all bets were off.
As usually happens, a bug report was filed and tracked:
The defect was finally fixed in February, 2010. The updated Chrome browser made its way out to folks in March, 2010.
The result was… not what people expected.
- File based Google tests for O3D samples and WebGL conformance == broken
- File based JavaScriptMVC == broken
- File based WebWorks Help 5.0 == broken
- File based WebHelp (most every help vendor out there) == broken
The same content, served up on a webserver, performed beautifully. It just stopped working when accessed from the local file system. This change to Chrome’s handling of the file://protocol hit anyone who made use of JavaScript with framesets or iframes.
Think help tool vendors, open source projects, end users, tech pubs == A Lot of People.
Is this the right thing to have done?
Maybe. It depends on where your focus lies. Google is focused on the Internet. Chrome is focused on the Internet. So the fact that Chrome is now fairly useless as a desktop browser shouldn’t come as a big surprise. I just wish Google would tell everyone and disable support for the file:// protocol in Chrome. Better to say “That’s not supported” instead of “Maybe it works, maybe it doesn’t”. Build a set of HTML files with JavaScript that obey every security requirement for web content, and you have zero guarantee that the same content will work when accessed from your local file system.
Google did give us a heads up about where they might take Chrome back in 2008 with a blog post entitled Security in Depth: Local Web Pages. I guess we can’t say they didn’t warn us.
What is WebWorks doing about this issue?
We already clicked that little star icon for Google’s current defect ;-). Now, we’re working on how best to make sure customers can continue to leverage ePublisher’s WebWorks Help output on the desktop. One way to accomplish this is by using Internet Explorer only on Windows. Details on the WebWorks Wiki. The other path to success is to find a way to deliver help using the limited environment Google offers. This is going to take a while longer to accomplish, if such a thing is even possible at all.
What can you do about this issue?
For starters, you can check out Google’s defect:
Issue 47416 – Allow a directory tree to be treated as a single origin
Hit the star icon in the upper left corner to let them know this matters to you. Please note that commenting has been disabled and the existence of 11 merged defects. Next, you can consider requiring IE or FireFox for your help content. If you are using the WebWorks Help API, you can configure it to always use IE instead of the system’s default browser. Other possibilities include generating simpler help output, using the Dynamic HTML format, or building native help. Microsoft HTML Help 1.x comes to mind for Windows based applications. These changes are easy to make with ePublisher (just add a new target), but difficult to integrate as they change the packaging and help APIs established for your products.
What else can you do? Talk to me. Leave a comment. Let’s see if we can find a solution for everyone, together.
