Google Chrome and WebHelp output

[cori]

I'm not a Flare user, but am trying to help a user at my company troubleshoot an issue with WebHelp output from Flare. We've built out help files and are planning to include the package in our upcoming release, but have run into a problem with Google Chrome.

When loading the WebHelp files from the local drive in Chrome, essentially nothing is rendered. I didn't dig *too* deeply into it, but it would seem that the output is running afoul of Chrome's local file Same Origin Policy implementation. I can also reproduce the same behaviour in Opera, from which Crome adopted much of it's local Same Origin policy.

When I place the same files on a web server, however, they render just fine.

Is this something MadCap is aware of, and are there plans to adjust for it?

I'm running Chrome 6.0.0422.0, and was able to reproduce the issue in both the standard and dev channels.

Thanks!

[RamonS]

I am not that familiar with the security model of Chrome or Opera, but in IE a similar restriction is in place and that one can be circumvented by enabling the "Mark of the Web" feature. It will generate the HTML files in such a way as if they were downloaded from the web. This might work out and show the files properly from local storage, but potentially generates problems when provided from a web server. Assuming the mark of the web works in the first place, you have to make a decision as to how the help gets distributed or make two versions.

[cori]

Thanks for the reply, RamonS, but it seems that MadCap already uses this technology to enable javascript in the local files for IE: there's already a generic about:internet MOTW in the .htm files, which both Chrome and Opera ignore.

[RamonS]

Maybe Opera and Chrome have their own way of dealing with that? If yes, you may be able to add this through a master page. Otherwise request it as a feature here: https://www.madcapsoftware.com/bugs/submit.aspx

[kevinmcl]

I'm writing this from Chrome (5.0.375.55).
This very moment, I have five browsers open. I'm viewing my (local) WebHelp in:
- Firefox 3.6.3,
- IE8,
- Safari 4.0.5,
- Opera 10.53

In Chrome, I'm viewing empty frames where my WebHelp is supposed to be.

So, is there a setting I can set in Chrome to allow it to properly display my WebHelp?
Something simple that I can also advise our customers to do?
The Help is distributed on a CD that accompanies our hardware and software.
It is most likely to live on the hard disk of the computer that's used to administer our product.
Or on a network drive at a customer's location.

If there's some connection with Opera, then Opera seems to have gotten over it...

Didn't Flare's dialog used-to say that if you switched on MOTW, your graphics would not be displayed? I haven't looked for a while, but I decided against MOTW years ago, based on the choice I was given by Flare at that time... seemed like a bad trade.

Thanks,

- Kevin

[LTinker68]

I haven't used Chrome much, but when I just tested it using a test project I also got a blank screen. I could see the frames, but the contents of all three were blank, regardless if MOTW was enabled or not. When I look at the Console output in Chrome, it's repeating thousands of lines of "Unsafe JavaScript attempt to access frame with URL...". At the very end (after 5,542 errors), I got "Domains, protocols and ports must match." To me that all sounds like security settings, but in a quick search I couldn't find how to add my local location as a safe location. You might have to do some research into how Chrome has to be configured to run the help from wherever you install it on the user's machine.

[kevinmcl]

We don't.

It works fine (for all other browsers) directly from the CD).
But since most people don't care to keep a CD in their drive all day, the end-user can copy the docs anywhere they please... and it should just work. We have no control over where they put it. It should also work fine if they stick it on a network fileserver.

UPDATE:
I just downloaded and installed the new Chrome Beta, and it has the same problem, so I sent a note asking them to fix the problem... while rubbing their noses in the fact that ALL other major browsers are fine with WebHelp.

If (as somebody indicated earlier) a previous version of Opera also showed the problem, then Opera seems to have caught on and fixed the problem in their 10.53 version (which is the only version I've got). So, Google should be able to figure it out.

It might be helpful if other Flare users were to try the Beta (or just say they did...) and report the problem to Google as well. That way it won't be just my lonely little voice. Be sure to mention your thousands of customers that you must instruct to use other browsers. Hit them in their ego. ;->

- Kevin

[kevinmcl]

Another UPDATE:

The problem persists with Chrome on Linux as well.

Haven't tried it with Chrome on Mac, but I doubt the outcome would differ.

So far, it looks like I'll be including a readme.txt file with upcoming product
releases, cautioning customers to use any browser except Chrome to view my WebHelp.

If a workaround is publicized (some security or "zone" settings in Chrome preferences, perhaps),
then the readme will have that instead.

- K

[LTinker68]

Can you view MadCap's knowledgebase in Chrome? That will narrow down whether it's something in your project or with running the help locally or if it's actually Chrome itself. If you can view the KB then it's the project or something internal to your environment. If you can't view the KB, then it's Chrome. MadCap's KB URL is http://kb.madcapsoftware.com.

[kevinmcl]

Yes I can.






UPDATE:
I just got a report from the Techwr-l list that Google is taking the issue seriously,
is addressing it along with another issue regarding JavaDocs, and has a fix in
the works - already being tested internally. Woohoo!

[32ndFlava]

kevinmcl- Do you have any updates on the fix yet from your source?? I did some research to see if I could find information on the web about chrome and this issue and ran across this:

Original Bug Report.
http://code.google.com/p/chromium/issue ... l?id=46167

Which was then merged into this Bug Report..
http://code.google.com/p/chromium/issue ... l?id=39767

And then ended up merging into this Bug Report...
http://code.google.com/p/chromium/issue ... l?id=47416

The last one had the comments turned off because of to much back and forth banter. I starred it to get notification, so lets see how this goes.

[kevinmcl]

Can you view MadCap's knowledgebase in Chrome? That will narrow down whether it's something in your project or with running the help locally or if it's actually Chrome itself. If you can view the KB then it's the project or something internal to your environment. If you can't view the KB, then it's Chrome. MadCap's KB URL is http://kb.madcapsoftware.com.

Lisa, I thought about this some more.

If the KB is simply served as files from a file server (as it would be from my hard disk or our company file servers), then your test would indicate what you suggest. But if the KB is served as actual web pages by a web server, then that might not be the same animal, and therefore would not tell us much about where the problem lies.

Yes, we've collectively moved on to assuming it's a Google-originated defect, but the logic of your test was pestering the back of my brain.


32ndFlava, I have no updates. I'm not doing anything to pursue it, and I haven't signed up for alerts from Google.
My alert will be when I next run Chrome and it says an update is available. I'll perform the update and try it again on my local webhelp.
Failing that, my next project goes out with a warning that its WebHelp can't be viewed by Chrome. That warning will be sent to every new - and upgrading - customer of ours for at least half a year.

In other words, I figure the ball is in Google's court.
Either all the other browsers are insecure, or Google has done something incorrect to their browser that breaks a long-established "standard" (WebHelp).

I suppose the only other question is whether WebHelp itself permits some sort of exploit... buaaaahahahahahahaaaa....
Because of the business I'm in (crypto, and data security) that would be a really bad development.

Let's hope it remains a browser issue, regardless.


- Kevin

[Mr Tagomi]

I'm not sure whether this is of any help to anybody, but I maintain the help systems for two web-based products, both of which have webhelp systems.

For differing reasons, neither of these is affected by the Chrome limitation, even though when I view the help directly from Flare, I do encounter the problem:

One of the products uses the following type of context-sensitive help call:

[help location]/default.htm#StartTopic=mytopic.htm

And the other calls the htm pages without the frameset.

I don't know why Chrome allows the help content to be displayed when called in either of these ways, but it does work.

[Andrew]

And the other calls the htm pages without the frameset.

I don't know why Chrome allows the help content to be displayed when called in either of these ways, but it does work.

I don't know about the first one you mentioned, but I'd imagine the reason calling the pages without a frameset works is because the cross-frameset communication is the security issue Google is blocking.

[kevinmcl]

Well, it's September 14, 2010, I just updated the Chrome browser on my system, and the problem is still present.

No fix from Google.

I wonder if they consider the deployed base of WebHelp systems to be just small potatoes on their scale, or...

I'd be surprised if they DIDN'T have Chrome reporting instances where it failed to perform such a task, so they likely have statistics on how frequently it occurs.

Of course, that kind of statistical data would be self-limiting. People try once or twice, realize that they can't use Chrome for viewing WebHelp, switch browsers, and then don't try Chrome for that again. Meanwhile, they use the other browser daily, but Google doesn't know that... oh... wait... they'd know that a certain PC (or Mac) was doing Google searches from (say) Firefox or Opera, where that PC had recently reported a Chrome cross-frame refusal...... nah.... they wouldn't bother.... would they?

- Kevin (paranoia will destroy ya)

[joy]

We have just discovered this issue during testing. I don't have the time or inclination to jump through hoops to get it to work with Chrome, so I will also be adding a "don't use Chrome" warning.

[Andrew]

Well, it's September 14, 2010, I just updated the Chrome browser on my system, and the problem is still present.

No fix from Google.

I wonder if they consider the deployed base of WebHelp systems to be just small potatoes on their scale, or...

Based on the Chrome bug threads linked above in this thread, it looks like this isn't a big priority issue, and it's quite possible that Google will never fix it. Their position is that it is a security problem. There have been several possible solutions bandied about, but I think any of them (well, any of the ones Google indicated it's willing to use) will require MadCap to change WebHelp to work again.

[tworks]

I'm writing this from Chrome (5.0.375.55).
This very moment, I have five browsers open. I'm viewing my (local) WebHelp in:
- Firefox 3.6.3,
- IE8,
- Safari 4.0.5,
- Opera 10.53

In Chrome, I'm viewing empty frames where my WebHelp is supposed to be.

So, is there a setting I can set in Chrome to allow it to properly display my WebHelp?

I am only able to get my WebHelp to open in Firefox. I get empty frames in
-IE8
- Safari 5
- Chrome
Kevin, do you mess with any settings to get the WebHelp to work in browsers other than Firefox?

[tworks]

One of our developers found a strange character in the htm and .js files and when he replaced it with "nothing," then my Web Help worked in all of the different browsers. The strange character was ""

The problem is that I will have to do a search and replace everytime after I publish my Web Help files, but at least it solved the browser problem.

[RamonS]

That is the byte order mark (BOM) of Unicode. I vaguely recall that there was a fix for it, but of course I don't remember. Might be worthwhile to search the forums for it.

[sarrants]

Still empty frames when viewing Webhelp with Chrome 7, updated today. Cleared cache and rebooted. No change.

[kristil]

I found the BOM fix mentioned here: http://forums.madcapsoftware.com/viewto ... ark#p41734
Does anyone why removing this lets it load? I'd like to be able to talk about it intelligently when I propose this possible solution to our developers.

We're troubleshooting the issue that WebHelp does not load in a QT browser in Windows. The QT browser uses WebKit, as does Chrome, so I'm thinking our problem is related.

[Andrew]

I found the BOM fix mentioned here: http://forums.madcapsoftware.com/viewto ... ark#p41734
Does anyone why removing this lets it load? I'd like to be able to talk about it intelligently when I propose this possible solution to our developers.

We're troubleshooting the issue that WebHelp does not load in a QT browser in Windows. The QT browser uses WebKit, as does Chrome, so I'm thinking our problem is related.

The Chrome issue here has nothing to do (as far as I know) with byte order marks. It's about cross-site scripting security issues. If removing the BOM fixes this issue, I don't think QT browser has the security problem that Chrome has -- I don't believe this is related to WebKit, as I do not believe Safari has this problem.

[dharrigan]

I'm a new Flare user and also just encountered this issue with WebHelp/Chrome.

I don't have anything to add...just replying to this thread so I'll get notified of any future posts on this topic.

[SteveS]

... and welcome to the forums!