This problem with Chrome has now been solved with Help & Manual 6, which introduces a free, single-file mini server called HM2Go. If you package this with your WebHelp it runs in its own local server, eliminating both the Google Chrome problem and the annoying yellow warning bar in Internet Explorer when you open WebHelp locally.
You can also use HM2Go with WebHelp produced with earlier versions of HM and even with WebHelp from other vendors. It is completely free and without any royalties, for both private and commercial use.
See this page for more information and a download link
************************************************************************
ORIGINAL POST ON THE SUBJECT:
If you open WebHelp files generated by Help & Manual locally in Google Chrome they won't work properly. Navigation links fail and the TOC remains "dead". This also happens to WebHelp from other vendors and many other HTML-based content like content management systems and e-learning systems. They all fail in Chrome when you try to open them locally instead of from a web server. What is happening? This article explains the background and why it's not possible to fix this problem in the short term without cooperation from the Google Chrome programmers. Unfortunately, they are not interested in cooperating.
This annoying issue is caused by a combination of a security algorithm in Chrome that can only be described as "unfinished", and a conscious policy decision not to change it on the part of the Chromium team (Chrome is based on the FOSS Chromium engine). I have corresponded with representatives of the Chromium team on the subject but they have stated that they have no intention of changing anything. It's not just affecting Help & Manual's Webhelp, other Webhelp is also affected, along with a lot of content management systems, e-learning systems and other complex HTML-based systems that are often also stored and opened locally.
I'll go into the details in a moment, but as far as solutions are concerned the situation is as follows:
- On the web/Internet or intranets with a web server there is no issue, everything works fine there.
- If the Webhelp is opened locally without a web server the only real solution is to start Chrome itself with the --allow-file-access-from-files switch, or to use another browser. There is no other way around the problem. However, starting Chrome like this isn't really something you can ask your users to do.
- What you *can* do, if you have a big Webhelp implementation and control over the installation along with your program, is to package a mini server like the FOSS Server2Go with your Webhelp and serve it up with that. This also has the added advantage that MSIE users don't get the annoying yellow warning bar about dangerous content, which is displayed for any local pages with any kind of scripting if you don't activate MOTW (which causes all sorts of other problems). I've played around with Server2Go and it appears to be an excellent project that is well supported.
So what is happening, and why is this such a problem in Chrome? A security feature in Chrome completely blocks inter-frame communication between frames that are not from the same domain. It affects "classic" frames in framesets and "modern" iFrames equally, because the frames themselves are functionally identical. You can use iFrames as drop-in replacements for normal frames with almost no code changes. Chrome's security feature provides excellent protection against cross-site scripting attacks that use injected iframes as their entry point. There's nothing to argue against there, this is very desirable and works very well.
The problem in Chrome's implementation of this arises when pages containing frames are opened locally. Since local pages have no domain information, Chrome simply assumes that all pages in frames contravene the same domain rules. Any page that doesn't return a domain identification is classed as being from an unknown domain, and since there is no way of knowing whether they all come from the same unknown domain, all communication between all frames is banned. No further checks are performed. It would be fairly trivial to introduce an alternative, like checking whether all pages were opened from the same local folder and having a blacklist of banned folders on specific operating systems, but the Chrome team is not planning to do anything like this at the present time, and so there is no solution.
In the long term we may be forced to drop frames entirely, even though it means making Webhelp less efficient and seamless, because they are increasingly being affected by new bugs that are not being corrected quickly because of similar disinterest on the part of the browser programmers. For example, there is a nasty uncorrected bug in the history stack in the version of Apple Safari on the iPhone and iPad that makes it impossible to use the history buttons without the address bar hanging in a frame-based site, which makes it look as though the page has frozen. On the recent updates to our Premium Pack skins and our dedicated iPad skin it was necessary to prevent the creation of history entries entirely on iOS devices. WebHelp now works on them, but you are not able to browse your history within the WebHelp because there is no history. Apple just reported that this bug will be corrected in iOS 5, but that is not due to be released before the autumn of 2011.