This was brought up today on techwr-l, and several people have confirmed that at least the latest build and perhaps the previous build of Chrome has issues displaying locally-viewed WebHelp generated from the following confirmed sources (there may be others):

• RoboHelp
• Flare
• Help & Manual

If you encounter this issue, please report it to Google to call attention to a needed fix. This will affect any of your audiences who use Chrome as their browser when viewing WebHelp. I’ve included a screen shot of what your users will see when they launch locally deployed WebHelp in Chrome.

A WebHelp system viewed locally using the latest build of Chrome

Update:

I just received the following comment on my reported issue.

Chrome broke local files which use cross-frame scripting or XMLHTTPRequest as part of a security update. It is intentional and no fix is planned, from everything I’ve read about it.

You can run Chrome with –allow-file-access-from-files to turn the security feature off and restore the functionality.

I asked how to do this, and this is the response I received:

It is a command line option, you have to go to the properties of a Google Chrome shortcut and add it to the end of the Target field, so it’ll look like:

“C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe” –allow-file-access-from-files

Note that only starting up Chrome from that shortcut will have the option take effect; starting it any other way will not (some people don’t seem to realize this).

FYI one recommended workaround (besides this switch) is for the developer to serve the html files off of a web server.  Not practical in all cases imo and yours is a good example of one.

It is a command line option, you have to go to the properties of a Google Chrome shortcut and add it to the end of the Target field, so it’ll look like:

“C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe” –allow-file-access-from-files

Note that only starting up Chrome from that shortcut will have the option take effect; starting it any other way will not (some people don’t seem to realize this).

FYI one recommended workaround (besides this switch) is for the developer to serve the html files off of a web server.  Not practical in all cases imo and yours is a good example of one.

Well that’s not good. Tell all users to bypass a formally rolled-out security update in their browser? Have them do it by command line? I don’t see that going over well. We all know the mess that ensued when Microsoft locked CHM down for local deployment only. We also know the solution that emerged: more people started developing browser-based Help. In fact, it’s the 2nd most valued user assistance deliverable! (per the 2009 WritersUA skills survey – 2010 results don’t seem to be available yet) Well, perhaps not for much longer.

I’m going to turn the question to the HAT vendors then:

• What is your advice on how to proceed short-term if a security update blocks your WebHelp functionality?
• What do you think the long-term solution will look like for locally-deployed WebHelp-like systems?

Update:

Looks like Google already is working on a fix for this issue. They ran into a similar issue with JavaDocs. Meanwhile some HAT vendors are also aware of the issue and are working on a fix on their end as well. I’ll let them speak up here with details if they so choose.

Related articles by Zemanta

• Google Chrome 5 Security Update (ghacks.net)
• Google Updates Chrome Frame, Makes IE Better (tech.slashdot.org)

{ 7 comments }