WebHelp not displaying in Chrome

[ruthmaryniuk]

I just built my Webhelp output (using Flare 9.1.1) and tried viewing it with Chrome - I get a blank 3-pane windo, no buttons, no content. If I view the same output in IE or Firefox, everything is fine. Has anyone else had this same issue? If so, is there a work around. It sounds like this is a Chrome issue.

[NorthEast]

I've just checked in Chrome (30.0.1599.69) and I get the same problem.

It won't display the help when it is on a local drive (file://), but the same help works fine on a server (http://).

[LTinker68]

Does enabling MOTW work with that version? I didn't think Chrome needed to use that for local viewing, but perhaps they're requiring that now. Or, if it's similar to what someone else reported for IE 11, then it needs a new doctype declaration (or whatever it was) added to the topics.

[ruthmaryniuk]

if it's as simple as adding a doctype declaration, please let me know. The client I'm working for at the moment delivers the Help with the product, so basically the Webhelp will be local. They do not want to restrict their clients from using chrome.

[amykk]

I reported this to MadCap on Monday. It's a bug that popped up as a result of the latest Chrome update. Support says the dev team is currently working on a fix.

[jcatlin]

I've had no problems with Chrome, ever. I'm not saying this to rub it in; rather, if I'm not getting the same issues, it must be a setting.

I do have Insert Mark of the Web checked for my targets. Has anyone tried this and still had problems?

[jamesw]

I have got mark of the web enabled, and I am experiencing the same problem that Chrome will not display local Web help anymore.
Unfortunately for me I have a release in 2 and a half working days. If anyone's got a workaround, you're my new BFF.

[jcatlin]

@jamesw, what do you have under Extensions? I have only two: Ipsum.com and Grammarly Lite. I know Firefox has given me fits in the past because of certain extensions (or too many, for sure); so, I've kept Chrome down to a minimum.

Also, what about your proxy settings under Settings > Network? (Probably not an issue, but I'm just throwing out ideas.)

[marvin mallari]

Hi folks,

In the interim, calling Chrome through the command prompt with a particular command will allow Chrome to view the webhelp manually.

Here are the steps:

• Open the command prompt
  Type the following string
  

  Code: Select all

   start chrome -allow-file-access-from-files

  Copy and Paste the path of the help into the address bar of Chrome.

[jamesw]

Hi all

For me, Chrome only has the Skype Click to Call extension, which is not enabled. There are obviously a lot of network settings but nothing looks untoward.
The -allow-file-access-from-files solution that Marvin suggested is unfortunately not suitable for the situation I'm in. That is, I distribute local Web help with an application that our developers produce. The main way that users access the help is by opening the developers' application and clicking a Help button in a dialog box (and so they get context-sensitive help). A secondary method of accessing the help is to click Help >Table of Contents on the Help menu in the developers' application. As it stands, the user whose default Web browser is Chrome (version 30? or later) will see a blank Web page. 90-something % of users will then give up on using the help as most of them are quite time-poor due to the stresses of their job.
If I could give them a setting that they had to change just once, that would be reasonable. However, the -allow-file-access-from-files solution requires them to do a workflow like this. Select URL, Copy, restart Chrome (having on one previous occasion added that switch to the desktop shortcut), paste URL at the top, press ENTER. Practically, I don't believe many users are going to do that.
For now I think my best option is to advise users to use a different browser other than Chrome (1 and half days to release). Still be interested if anyone has any other ideas though, and thanks Marvin and jcatlin for your replies anyhow.

James

[RamonS]

James - the application could have code that checks for the default browser. If it is Chrome then Chrome can be started explicitly from the shell with the parameter included. The question is if releasing a new version of your software is worth the effort for a hopefully temporary fix.
Welcome to the frustrating world of browser based applications. Until no we had to pull tricks to get the craptastic IE to behave, now Chrome comes into the mix requiring yet another tweak. Thanks Google!

[Scotty]

Any real resolution to this issue from MadCap by way of a fix? I'm back on Flare 7.2.1. Chances of this version also getting a fix?

If there's no official fix via a patch, is there something we can do manually (e.g. to the outputted .htm files)? Using MOTW didn't work for me and is a pretty dirty solution. WebHelp being unavailable in the most widely used browser is completely unacceptable from a business perspective.

[RamonS]

I cannot speak for MadCap, so if you want an official answer you need to contact MadCap support. That said, chances are low that a patch comes out for v7 but I do not know what the maintenance period is for Flare. If there is a means to modify the HTML files in the output so that the help works with newer Chrome versions then you could add this after generating output (batch script). So far I did not see any solution for this. MOTW is special to IE and is ignored by any non-IE browsers.

[jbananak]

The response I got from Madcap support was that since Google changed their code - by surprise, they could not foresee this.
There is to date no patch for Flare 9 (the latest version). And there will be NO patch for earlier versions as they don't release patches for earlier versions (I have 8.1).
Meanwhile, not being a programmer, I'm not sure what to tell my programmers to do to make it work in Chrome..
Is there a line of code that can be embedded within the software application which loads the HELP (which is embedded in the application and not on an online server) - that will tell the user to open the help each time in Internet Explorer - even if the users default internet application is Chrome?

Thanks
Joanna

[RamonS]

Flare version 9.1.2 supposedly fixes this.

[Msquared]

Here's the equivalent post on LinkedIn, and a possible solution to your question about how to force the webhelp to open in IE. My aplogies if you're already following this discussion.

http://www.linkedin.com/groups/Google-C ... Egmr_86373

[alanandrew]

Hello

This problem started in Flare 8.1.2 when Chrome was updated to v30. I had to downgrade to Chrome v29, then all was OK again. I think a fix was released for Flare v9, but does anyone know of a fix for Flare v8? This is important because my clients will almost all have their Chrome browsers auto upgrade and then Flare v8 Webhelp will just stop working.

Remember that it takes money to upgrade to Flare v9.

Thanks all, hope you can advise.

[RamonS]

It was answered in a different post and the answer was no. There will be no patches for v8, but I cannot speak for MadCap. Best option is to contact them directly. As far as money, it costs money to upgrade anything that is not open source, so Flare is not different here. And with a maintenance contract you are guaranteed to get the next version included.

[dsch_tw]

I have a different twist to this situation. My published WEBHELP displays correctly from our application on IE9 and Firefox, but on the latest Chrome 30.xxxx, the content files are updated BUT the old intro page still appears, even though I purged it from the project. Also, the old TOC appears, without the new topics I added, even though those new topics are accessible from other pages. Plus the outdated TOC contains a link to a deleted file, but in this case, that file still opens. I've checked it several times. I completely cleaned the Published Destination folder. But it turns out that these problems are only appearing on Chrome, while the WebHelp displays perfectly on the other major browsers.
The question is if this is a Flare-to-Chrome bug, or our application-to-Chrome bug.

David

[RamonS]

I think it is more a caching issue on the Chrome end. Clear the browser cache and see if that fixes things.

[dsch_tw]

Ha!
Ramon, your suggestion worked! Thanks so much.

David

[alight]

I was having the exact same issue using Chrome and WebHelp. Updating Flare to 9.1.2 fixed the issue.

[KJohnsonDBTK]

We saw the Chrome issue too, and the 9.1.2 update fixed it, but it has broken our context-sensitivity within our application. When you press F1 in the application, the help shows up blank, basically like it did in Chrome before the Flare 9.1.2 update. I still need to gather some particulars about how the help is opened and displayed (I believe it renders using an IE engine, although an IE browser does not actually open), but I wanted to post to see if anyone has experienced anything similar since upgrading to 9.1.2. Thanks