Issues with WebHelp in Google Chrome

The latest news, information and updates.

Moderators: Alexander Halser, Tim Green

Post Reply
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Issues with WebHelp in Google Chrome

Unread post by Tim Green »

Update 2012: Problem solved

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.
However, that is the limit of what is possible. There is no other way around this unless one of two things happens: Either the Chromium team cleans up their code and makes it work properly locally, or we stop using frames entirely in our WebHelp. The problem is, the Chromium team has stated categorically that they have no intention of changing anything, and removing frames is not a short-term option. Even the completely overhauled version of Webhelp we are working on at the moment still uses iFrames to contain the navigation and topic files. This is because they are the only inexpensive way to provide a seamless fallback with a navigable page for users who have scripting turned off. If you don't use iFrames you can only load external pages with scripting and Ajax. Providing a noscript fallback from that is much less seamless, and we'd like to avoid it if at all possible.

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.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Hayden
Posts: 35
Joined: Thu Jul 31, 2008 2:41 am
Location: Dunedin, New Zealand

Re: Issues with WebHelp in Google Chrome

Unread post by Hayden »

Thanks for the update.
For our team this is what broke the camels back. Our solution was to build our own chromium-based browser into our software. This by-passes many of the security issues with local content that external browsers experience.
Hayden
Posts: 35
Joined: Thu Jul 31, 2008 2:41 am
Location: Dunedin, New Zealand

Potential Solution

Unread post by Hayden »

I have been hacking away and I have come up with the beginnings of a potential solution.
It involves using the postMessage method (https://developer.mozilla.org/en/DOM/window.postMessage)

In the head of the content html page template I added:
<script type="text/javascript">
function sendmessage() {window.parent.frames.hmnavigation.postMessage("<%HREF_CURRENT_PAGE%>","*");};
</script>
<body onload="sendmessage();">

In the Table of Contents HTML page template I added:
<script type="text/javascript">
var onmessage = function(e) { lazysync(e.data);}
if(typeof window.addEventListener != 'undefined') { window.addEventListener('message', onmessage, false);}
else if(typeof window.attachEvent != 'undefined') { window.attachEvent('onmessage', onmessage);}
</script>
<script type="text/javascript" src="navigation2.js"></script>

The navigation2.js is a modified version of the normal navigation js file but I deleted all of the "hmnavigation." so hmnavigation.document.getElementById("tree"); becomes document.getElementById("tree"); etc.

I was able to get the content and the navigation in sync in Chrome using this method. Chrome throws a bunch of javascript errors, but with a bit of clean up it shouldn't be too hard to make it work nicely.

What do you think? Possible fix for future webhelp H&M versions
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Issues with WebHelp in Google Chrome

Unread post by Tim Green »

Hi Hayden,

We're aware of the postmessage hack, this was actually what the Chrome programmers suggested we used. However, we refuse to do this on principle because it means going back to the bad old days of lazy and sloppy browser programmers expecting web designers to do their dirty work and clear up their mess for them. Chrome is broken and intentionally broken, this "security feature" breaks HTML standards and it is something that the Chrome programmers need to fix. We are not going to fix it for them. :roll:
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Scott Steketee
Posts: 15
Joined: Thu Nov 12, 2009 3:08 pm

Re: Issues with WebHelp in Google Chrome

Unread post by Scott Steketee »

Hi Tim,

Perhaps I am missing something -- it seems that your recommended solution, using HM2Go, is Windows only. Is there a Mac version of this mini-server? If not, what do you recommend? Assuming Hayden's solution is cross-platform, would this not be a better choice for our cross-platform product?
--Scott
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Issues with WebHelp in Google Chrome

Unread post by Tim Green »

Hi Scott,

HM2Go is currently Windows only, so you can try Hayden's solution. Another alternative would be to try out the beta OS X Version of Server2Go, which is already a very mature solution for doing the same thing as HM2Go, with additional support for things like PHP, MySQL, Perl and so on:

http://www.server2go-web.de/features/mac.html

You do need to be a donating supporter to access the beta, but I can highly recommend Server2Go. It's an excellent solution with very responsive support. 8)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply