Problem with DITA Webhelp in Chrome

[OxgenProspector]

When I generate WebHelp from my DITA project and display it in Chrome I get the error message:

"The page at file://localhost/ says:
Please note that due to security settings in Google Chrome you will be redirected to webhelp frameset version!"

Then if I press OK the Content menu button changes from "Content" to "C Content" (that's correct a repeated C) and pressing the Search button causes nothing to happen.

If, on the other hand, I press Cancel on the error box the menu buttons Content and Search work correctly but the content frame on the right is always blank no matter what is selected in the Content menu.

Any ideas

[sorin_ristache]

Hello,

The warning about the Chrome security settings is due to the restrictions that the Chrome browser imposes on JavaScript code run from the local filesystem. You can avoid this warning only by loading the Webhelp pages from a Web server (http://...) instead of the local filesystem (file:///...), even if the Web server runs on the local computer.

The problem with doubling the C in C Content and with the blank right side panel was fixed in one of the previous Oxygen maintenance builds. What version and build number of Oxygen do you run? Please download and install the latest build number for your Oxygen version for fixing this problem, or better download the latest version (15.1).


Regards,
Sorin

[OxgenProspector]

Thanks for the accurate and quick reply. I'm running 15.1 build 2013101713. I can live with the Chrome warning message but will the search button work for a local file. My purpose is to deliver a downloadable piece of software with a local help file. Should I just stick to PDF for that purpose?

[sorin_ristache]

When I generate WebHelp from my DITA project and display it in Chrome I get the error message:

"The page at file://localhost/ says:
Please note that due to security settings in Google Chrome you will be redirected to webhelp frameset version!"

Then if I press OK the Content menu button changes from "Content" to "C Content" (that's correct a repeated C) and pressing the Search button causes nothing to happen.

If, on the other hand, I press Cancel on the error box the menu buttons Content and Search work correctly but the content frame on the right is always blank no matter what is selected in the Content menu.

Actually you are right, I can see now that in the latest version of Chrome one cannot switch between the Content and Search tab anymore, besides the wrong tab name (*C Content*). We will look into it.

To avoid the Chrome security restrictions imposed on local files (loaded with a URL of the form file:///...) I recommend loading the Webhelp pages from a web server (with a URL of the form http://...), regardless of the actual location of the Webhelp files (local or remote). The point is to load the pages by HTTP in Chrome to avoid the Chrome security restrictions.

I can live with the Chrome warning message but will the search button work for a local file. My purpose is to deliver a downloadable piece of software with a local help file.

The answer for now is: no, the Webhelp pages cannot be used in Chrome as local help files (loaded in browser as file:///...).

These problems do not occur in other browsers (Firefox, IE, Opera) because they do not impose these security restrictions for local files, so other option is loading the Webhelp pages as local files in other browsers instead of Chrome.


Regards,
Sorin

[OxgenProspector]

The problem, as I see it, is that I don't have any control over what users have setup as the default web browser on their system, so those with Chrome will just see a webpage that appears not to work. I can try to generate some kind of warning message during installation etc. but chances are most users won't read the warning.

Now assuming the two button issue is fixed, would I need to install a local webserver on the end user's local machine so that they can access the local help webpage through http:// on Chrome. Or is a local webserver part of every Windows and OSX system these days so that I just have to change the path from file:// to http://. As you can see, I'm kind of ignorant about these matters.

You can see my temptation to avoid the whole thing by just using PDF. Everybody on Windows and Mac now has a default PDF viewer that shows a nice TOC and has search capability, and PDF formatting generally looks better anyway.

The main advantage for webpage format seems to be that if you do access it over the internet you don't have to load the whole document -- like you would a PDF. I might do that also as a separate matter in which case Chrome would apparently work fine. But I still want to deliver local self-contained help.

BTW I am in Oxygen eval mode. Just to see what happens I also demoed XMLMind. In fact I prefer Oxygen which seems to be more comprehensive, but XMLMind is able to generate a local webhelp output with search that doesn't generate any messages or malfunctions with Chrome. So there must be some kind of trick that gets around the Chrome local security issue. Or maybe I just happen have a local webserver installed that I don't know about and they used http:// when the opened the local help.

[sorin_ristache]

The problem, as I see it, is that I don't have any control over what users have setup as the default web browser on their system, so those with Chrome will just see a webpage that appears not to work. I can try to generate some kind of warning message during installation etc. but chances are most users won't read the warning.

Starting with the next version we will improve the message in the warning dialog box that the index.html version of the Webhelp displays as the first thing in the Chrome window for local files (file:///...), so that this warning message will explicitly recommend loading the Webhelp pages from a web server (http://...).

Now assuming the two button issue is fixed, would I need to install a local webserver on the end user's local machine so that they can access the local help webpage through http:// on Chrome. Or is a local webserver part of every Windows and OSX system these days so that I just have to change the path from file:// to http://. As you can see, I'm kind of ignorant about these matters.

Any normal web server will do. The important thing is to load the pages in Chrome using an http://... address.

You can see my temptation to avoid the whole thing by just using PDF. Everybody on Windows and Mac now has a default PDF viewer that shows a nice TOC and has search capability, and PDF formatting generally looks better anyway.

Oxygen includes a built-in transformation for PDF output for both the DITA framework and the Docbook one. If the final PDF document is not overly large this is certainly an option. The larger the PDF document, the slower the PDF viewer, I suppose, unlike the Webhelp on-demand page loading strategy.

BTW I am in Oxygen eval mode. Just to see what happens I also demoed XMLMind. In fact I prefer Oxygen which seems to be more comprehensive, but XMLMind is able to generate a local webhelp output with search that doesn't generate any messages or malfunctions with Chrome. So there must be some kind of trick that gets around the Chrome local security issue. Or maybe I just happen have a local webserver installed that I don't know about and they used http:// when the opened the local help.

Maybe they don't use XHTML internal frames as in the index.html version of the Oxygen Webhelp output.


Regards,
Sorin

[urbanrobots]

Does Oxygen plan to support a local version of the webhelp that works in Chrome? We have the same problem of supplying a webhelp folder to customer who will download and look at the html files locally. We don't know what browsers they will use.

Also, is there any way to change the frames so that the banner on top is one frame and the ToC and body are other frames? In the frame version now, the title is squished on the top-left frame with the body frame taking up the whole right side, but we would prefer the banner to fill the top portion at least.

Thanks,
- Nick

[Costin]

Hello,

If the output was generated using Oxygen v17, in order to use the search function from the default page ('index.html'),
the WebHelp output must be placed on an HTTP server (e.g. Apache), rather than on your local file system.
This is because the search cannot be used when the files are local, because most of the web browsers prevent local files being accessed by the Javascript code.

When working with local files, if you need to search in WebHelp content, you should use the 'index_frames.html' file instead of 'index.html'.

Regarding your other question, related to the frames customization, another colleague of mine specialized on WebHelp development will provide an answer soon.

Regards,
Costin

[bogdan_cercelaru]

Hello,

Also, is there any way to change the frames so that the banner on top is one frame and the ToC and body are other frames? In the frame version now, the title is squished on the top-left frame with the body frame taking up the whole right side, but we would prefer the banner to fill the top portion at least.

Unfortunately this cannot be done using the current implementation.

Regards,
Bogdan