- Image via Wikipedia
As reported yesterday, an update to Google Chrome has crippled most browser-based Help formats as well as JavaDoc. Google has been active in developing a solution, as evident in reported incidents 46167 and 39767. While there is a current means around this, it involves bypassing file action restrictions via the command line, which is likely something most if not all product developers would rather not instruct their customers to do.
The fix as outlined in issue 39767 has been implemented in the Chrome trunk and is being tested. Reports so far from those testing is that it is working, but details are thin. I cannot tell at this time whether they are merely testing JavaDoc or if they are testing all cross-frame scripting scenarios.
Tim Green, head of documentation, user support and template development at EC Software (makers of Help & Manual) shared his thoughts on the HATT list:
We’ve been experiencing this issue in Chrome as well with the Webhelp generated by Help & Manual, which currently still uses frames for maximum backward compatibility with old browsers. However, our tests indicate that this problem also exists with iFrames as supported by HTML5 and possibly also with objects or divs if you load external files into them with a number of different methods.
I’ve been corresponding with the bug list managers at Google on this. It is not yet entirely clear which of two issues is causing the problem. It currently looks most likely that it is this one:
http://code.google.com/p/chromium/issues/detail?id=39767
If this is the case it has been identified as a bug and this is due to be fixed soon with an upcoming patch to Chrome/Chromium. However, it is also possible that it may be this issue:
http://code.google.com/p/chromium/issues/detail?id=40787
Apparently the console error messages generated when the problem occurs can’t currently be trusted entirely, they may be spurious. If it is 39767 the problem should go away when the patch is published. However, if it is 40787 it may continue, and that would be more serious. This would mean that it is being caused by a new block on “cross-frame scripting”, which would essentially break many Webhelp implementations in their current form when opened from local drives, which need to communicate between frames, iframes or other containers to work properly. It may be possible to get around this with the sandbox=”allow-same-origin” attribute introduced for iFrames in HTML5, but we haven’t done testing on that yet, and it would require HTML5 support in browsers to make it work.
What can be done now:
At the moment there are two reliable ways to make Webhelp affected by the issue work in Chrome, neither of them are very satisfactory:
- Start Chrome with the –allow-file-access-from-files switch in the command line. This will work but it’s not really something you can ask users to do.
- Use a local web server like the free server2go and integrate it in your help system
This gets around the problem entirely because it opens your help in its own local web server environment, which takes it out of the problem area of being opened as local files. This too is not exactly a simple solution, but it has the advantage of being transparent to the user if you set it up properly. It also works on CDs etc, and has the added advantage of eliminating the “yellow warning bar” problem in Internet Explorer for Webhelp opened locally, and this is much more effective that using the MOTW (Mark Of The Web) for this in IE, which causes all sorts of other problems.
If it does turn out to be cross-frame scripting blocking, and if other browser programmers feel driven to implement this as well, then we may eventually have to start using local servers for Webhelp on a broader basis.
Tim later followed up with a bit of information specific to Server2Go that he forgot to mention in his post to HATT:
Server2Go currently has a small bug with Webhelp in Firefox that causes the server to close on… you guessed it … cross-frame scripting requests. The programmer is aware of the problem and has promised to have a fix for it out soon. Other than that Server2Go looks like a great solution, also for Webhelp installations on CD.
This is an interesting solution, but it raises a few questions. First, can the local web server be deployed fully configured with services running on product install? Second, what if the target machine is restricted in some manner (I’ve seen all sorts of odd IT restrictions to prevent people from messing up their systems, with many of these restrictions reaching flawed levels)? What about the installing user’s machine rights? And would this beg for altering every product’s system requirements just to satisfy online Help?
If the issue is indeed as hairy as in issue 40787, this could affect any locally deployed web-based system using scripting to control content between frames, not just browser-based Help and JavaDoc.
Related articles by Zemanta
- Google Chrome 5 Security Update (ghacks.net)
- Apple (Yes, Apple) Helps Fix A Couple Chrome Security Bugs (techcrunch.com)
{ 3 comments }
