Google Chrome == Internet Yes, Desktop No

Posted on: September 22nd, 2010 11 Comments

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:

Issue 4197 – Further restrict access of file URL

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.

11 Responses

  1. John Pitt says:

    IBM got too big for its boots; and was trounced by Microsoft. Microsoft got too big for its boots; and was trounced by Google; Google got too…


  2. Bruce Frederick says:

    I’m surprised this hasn’t raised more of an outcry. There was a flurry of postings across the web when this first surfaced, but then it died down.

    It’s certainly a big deal to us, and if MSIE and FireFox follow this path, it’s going to be a huge problem. I don’t savor the thought of trying to add a web server to our installation just so users can access our help.

  3. Brett says:

    Thanks for the info. I was wondering why Chrome kept coming up blank when I clicked “Yes” after I “generate all”.

  4. Jake says:

    Sorry, even the hosted stuff is broken. I get a blank screen and “Uncaught ReferenceError: WWHFrame is not defined” in the JS console

  5. allums says:


    We have not seen that issue in our testing with recent Chrome builds. Please open up a support case so we can review the problem with you.


  6. Mike Hedblom says:

    I’ve been told the problem can be solved by adding this command-line property to the command that launches Chrome:


    For example, in the browser shortcut -> property -> target.

  7. Akash Kava says:

    I have added one more issue and I have also clicked on Star, this is very ridiculous behavior by chrome developers.

  8. Keith Yarwood says:

    Is this still an issue with recent versions of WW (ePublisher)? We are using an old workflow with WW 2003.

  9. allums says:


    Yes, Google Chrome still operates this way.

    While we have not address this issue with WWHelp, we did fix it for our WebWorks Reverb format. Reverb is an HTML5 based, mobile ready format that can be used either on the desktop or on websites with good performance. Like WWHelp, Reverb supports context-sensitive help, direct linking to pages, merged help sets, etc.

    To date, Google has shown no interest in addressing this issue for desktop users. Enabling Reverb to operate in the environment took effort, but then it was designed for modern browsers. WWHelp’s design precludes any easy solutions.

  10. Keith Yarwood says:

    Thanks. Where can I get detailed information re. WW Reverb?

  11. allums says:


    You can learn more about WebWorks Reverb by viewing our online documentation, available in the Reverb format.

  12. Chi says:

    you have zero guarantee that the same content will work when accessed from your local file system. mozilla firefox pc

  13. Chi says:

    you have zero guarantees that the same content will work when accessed from your local file system.

  14. Chi says:

    thanks for sharing nice post!

Leave a Reply