Skip to main content
K
kmaddox1
Inspiring
January 17, 2013
Answered

issue with RH10, Zoomsearch, and Firefox

  • January 17, 2013
  • 1 reply
  • 2501 views

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/whproxy.js

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.

This topic has been closed for replies.
Correct answer 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


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

1 reply

Peter Grainge
Community Expert
Peter GraingeCommunity Expert
Community Expert
January 17, 2013

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

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.
K
kmaddox1Author
Inspiring
January 17, 2013

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

K
kmaddox1Author
Inspiring
January 18, 2013

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


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

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices