issue with RH10, Zoomsearch, and Firefox

[kmaddox1]

We are having an issue with Robohelp 10, ZoomSearch, and Firefox. Here's what is going on:

Last year, we successfully implemented Zoom Search on a merged helpsystem on  RoboHelp 9 (WebHelp layout and Java search). Everything worked as described in IE, Firefox, and Chrome and people liked the new search.

This month, we upgraded the entire help system to Robohelp 10 and followed the same steps to implement ZoomSearch on the published files. Everything works exactly as before with IE and Chrome, and the parent and child help systems display just fine in Firefox. All good news.

However, when we click the Zoom Search button from the parent project using a Firefox browser, things stop working. The right-hand frame momentarily displays "Search loading, please wait," followed by a blank page, and the browser goes into in an endless "Connecting" loop.  That is, it appears that something in the redirect from search_options_redirect.htm (the file attached to the Search button in the parent project's skin) does not work using RH10 and Firefox even though the same redirect works in IE, Chrome, and Windows Explorer.

When we run Firebug in Firefox, Firebug displays the following error:

Error: Permission denied to access property 'whname'

file:///C:/RTPONEDocumentation/OneHelp/generate/mergedProjects/RTPOneAdministrationUsersGuide/whprox...

Line 10

This error is repeated endlessly. RTPOneAdministration is the main project for the search.

I don't know enough about js files to debug the problem but I'm suspecting there's something in the RH10 version of this file that FIrefox doesn't like.  It does appear that the RH9 version of whproxy.js is different than the RH 10 whproxy.js.

Can anyone suggest how to address this problem? I really don't want to have to tell our customers that they can no longer use Search if they are using Firefox.

[Peter Grainge]

I will upgrade a project that uses ZoomSearch to Rh10 and see what happens. It is evening here though so it will not be today.

Is this problem occurring with the help both locally and on the server?

Does the problem still occur with Firebug disabled? It would not be the first time webhelp has hit issues with Firebug enabled.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kmaddox1]

Thank you, Peter! I was just remarking to my co-worker that I hoped that we might get some sort of helpful reply from Peter Grainge tomorrow...but you beat my prediction by a day!

The issue appears to happen whether or not Firebug is on. We only turned on Firebug after we initially saw the problem to see if we could get more information. I did Google the error message "Permission denied to access property" and found some Firefox-related hits, but I'm not savvy enough to understand what the developers were saying. Something about redirects, using the same domain, and iframes if that's helpful.

The issue occurs in two different help systems and on two different local computers, but we have not yet published the RH10 version to our network server.  We can try that today and let you know what happens.  We've also tried implementing ZoomSearch in the Generate folder with the same results.

Thanks again for your speedy reply. I look forward to hearing your results.

Kathy

[Peter Grainge]

I am seeing the same problem running the test locally but once it is uploaded to the server it works as it should.

It does seem to be specific to merged help so it would help me if you can provide a link to whichever site you thought explained it best.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kmaddox1]

Hi Peter,

Thanks for testing and for your update.

It is interesting that you could get Zoomsearch to work with Firefox when you uploaded the files to a server. Are you referring to a web server or to a server on your network? And did you simply copy the published/indexed files to that server or publish to that location and do the indexing from there? We have tried both approaches to get the published RH10 files to our network server, but we are still unable to get Zoomsearch to work with Firefox.

However, we did made some other progress. This is what we found:

1. We managed to get the ZoomSearch button to work by moving the search.html file to the parent project (as well as the associated search.js files), and updating the redirect line in search_redirect_options to point to the new location in the same folder. We were then able to search for text across project files and open up PDF files from the search results. Minor victory. Unfortunately, we were  not able to open up any HTML files in the search results in Firefox (that is, we couldn't open topics in the child projects from the results).

2. We can get ZoomSearch to work with Firefox if we generate or publish the help using the command line prompt for RoboHelp 9 against the RH10 files. We discovered this inadvertently. Our s/w build process includes steps for generating the help using a command-line script and for reindexing those files with Zoomsearch, but the developers haven't gotten around to installing RH10 on our build computer. So after they ran the build yesterday (for the first time since we upgraded the files to RH10),  we were surprised to see that ZoomSearch in their version works just fine with Firefox. We then tried publishing our RH10 help projects locally using an RH9 command line. Zoomsearch now works fine on our local PCs. Go figure.

As for the links I viewed, there isn't one that I would say was particularly helpful. But there were a lot of hits on "permission denied to access property  firefox" that discussed issues related to trying to access iframes across domains. I don't know how that relates to using ZoomSearch in merged help but I suspect there's something in the format of the redirects to the Zoomsearch page in RH10 that Firefox considers illegal. 

Kathy

[Peter Grainge]

What I did was take a RH8 merged demo that had ZoomSearch already set up. I regenerate that and republished it to a local drive. The method on my site uses the published output that has been published locally.

I then tested that and got the problem you report. My get feel was the issue was because the help was being run locally. I had in mind the Chrome issue with local help and thought maybe something in FF didn't like what Rh10 was generating. My hope then was that with the help on a web server, the problem would go away, just as the Chrome issue did.

So I used FileZilla to put that on my site. http://www.grainge.org/demos/rh10_zoom if you want to take a look. It's basic but it is enough to prove the point.

I think where we are is that something has changed in Rh10 that invokes the problem you found described by searching. The problem I have is that it would take a developer or someone with code skills to identify that problem. I cannot realistically ask Adobe to look at a problem that only arises when using a third party search tool. Maybe Wrensoft would help, I will ask them.

I do think it is essential that the help is on a webserver rather than a network server. Very different configuration.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kmaddox1]

yup, your demo works just fine for me using Firefox.  Unfortunately,  we don't publish our help to a web server. Instead, our help system is included with the software. When customers install our s/w, they deploy the published help and Zoomsearch files on a network server at their site. 

Note that we just  tried publishing the RH10 files with a RH10 command line. Firefox/ZoomSearch still doesn't work (though it did when we published  the same files with the RH9 command). So I agree that something has changed in Rh10 to invoke this problem.

I completely understand that this isn't really Adobe's issue and it's not really Wrensoft's either. But it would be great if you could ask either or both company for ideas. I'll also see if I can get our web developers here to take a look. 

Fortunately, we are  already planning to change how we provide help to our users. Our help system has grown exponentially and customers are complaining about how long it takes to install. So we are planning to start hosting the help system on a web server here. It is good to know that ZoomSearch and Firefox will work in that context.

Thanks,

Kathy

[Peter Grainge]

Kathy

One solution if all else fails would be for your developers to look at something like Server2Go. That creates a web server environment on any drive. Not sure if it would be 100% satisfactory, you would have to test that.

I will take a look at some other options that have occurred to me but that will not be for a little while.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge · Accepted solution]

Woo hoo! I do believe I have resolved the problem.

What puzzles me is the solution is something I had to introduce in my Merged Help instructions for RoboHelp 7 when Firefox 3.0.9 caused a problem. Why it has only just surfaced in Rh10  is one of life's mysteries.

Take a look at Adding a Redirect at http://www.grainge.org/pages/authoring/merging_webhelp/merging_method_rh9.htm#5

At the moment your parent project has a meta tag

<meta http-equiv="refresh" content="0;URL=./mergedProjects/child_1/search_files/search_options.htm" /

You need to delete that.

Immediately above the closing </head> tag, then add

<script language="JavaScript" type="text/javascript">//<![CDATA[

<!--Script courtesy of http://www.web-source.net - Your Guide to Professional Web Site Design and Development //-->

var time = null

function move() {

window.location = './mergedProjects/child_1/search_files/search_options.htm'

}

//]]></script>

Please do not remove the credit, it is a condition of use.

Then amend the <body> tag to read

<body onload="timer=setTimeout('move()',100)">

It should only take a few minutes and after that I think you will find it all works correctly in FF, IE and Chrome.

Please confirm that it works for you and I will then amend my instructions.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[kmaddox1]

Hi Peter,

Woo hoo indeed! You did fix it! The only adjustment we made--after making the changes you suggested--was to move the search.html page into the same directory as the search_options_redirect.htm page (that is, we moved the search.html page and the associated js files to the root of the parent directory).

If you leave it like we had it (the search_options_redirect.htm redirects to the \mergedProjects\childProject\search_files directory), Firefox opens the search.html page and you can conduct a search, but when you click the link to the topic, the same endless loop occurs again.

Thank you so much for your help,

Kathy and Bonnie

[Peter Grainge]

I'll take another look tomorrow.

[Peter Grainge]

Almost certainly the need to move stuff is because your ZoomSearch configuration is wrong. I say that because after a LOT of poking around, I found that my demo file was wrong and I apologise for that.

In ZoomSearch you have to state what gets searched and where the results are to be published. In between a relative path has to added and that was wrong.

The end result was that you get the search results and you think it is all OK. It goes wrong when you click the link in the search results.

Whilst I got the original Connecting problem, that was only when the Search button was clicked. My earlier fix for that is only needed in the search_redirect file.

I have tested in both Rh9 and Rh10 and the demos both work correctly now. I will be updating my site but I will send the Rh10 one to you first and would be grateful if you would confirm it is OK in your environment.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge