Firefox Does Not Display Topics When Using "#" in the URL

[Guest]

I'm currently having a problem with Firefox not opening context-sensitive help links using URLs, rather than map IDs. For example, if the URL is http://www.myhelp.com/index.htm#custom_topic.htm, Firefox will load the page as expected (except it appears to continue loading the page, which is another issue that is discussed in another forum), but either immediately loads the parent topic (if the requested topic is a subtopic in a book) or displays a "Page Cannot Be Displayed" error. It's peculiar in that the correct topic loads (the one after the octothorpe), but Firefox (or WebHelp--I'm not sure who's to blame here) then goes to the parent topic or displays the error. Any guesses?

[Peter Grainge]

The # method normally works on Firefox so there has to be some other reason.

The loading not completing is, as you say, another issue and there is a topic about that on my site.

You could try a ? mark instead of the # but I doubt that is it. Normally topics will only open another if they contain a redirect.

Re the Page cannot be displayed, could it be the server is Unix based and you have a mismatch of case?

Have you tried creating a small test project and seeing if you get this problem?

[Guest]

Hi Anthony,

Not sure about the "Page Cannot Be Displayed" message, but by "parent topic" do you mean the first topic in the book? If so, is that topic linked to the book? There is a known problem with Firefox displaying the topic linked to the book, rather than the selected topic, when you link to a different topic in the book.

The only workaround I could find was to remove the links between books and topics in WebHelp.

Here's the original thread.

If this is totally irrelevant, please ignore!

Anne

[Helen3308]

I have the same problem with firefox 2.0.0.1

The page will immediately loads the parent topic or displays a "Page Cannot Be Displayed" error. I tried to add "?" in front of "#", but it still doesn't work.

If I remove the following lines from header, the topic will stay, but I cannot use the navigation and synchronize topic without those javascript files. Is there a solution to solve the firefox problem?

<script type="text/javascript" language="javascript1.2" src="../../../whmsg.js"></script>

<script type="text/javascript" language="javascript" src="../../../whver.js"></script>

<script type="text/javascript" language="javascript1.2" src="../../../whproxy.js"></script>

<script type="text/javascript" language="javascript1.2" src="../../../whutils.js"></script>

<script type="text/javascript" language="javascript1.2" src="../../../whtopic.js"></script>

Thanks,

Helen

[Peter Grainge]

You should not need to mess with those files.

With a merge on my hard disk, the following opened correctly for me with Firefox 2.0.0.1

file:///D:/cedarhelp/help_home.htm#mergedprojects/00main/helphome/whats_new.htm

What path are you entering in Firefox?

[Helen3308]

Hi Peter,

Thanks for the reply, the URL I entered in firefox is
http://www.mcssl.com/netcart/webhelp/user_guide.htm#Learning_The_Software/Main_Menu_Text/Products/ad...

Please try it and let me know if this can be fixed.

Helen

[Peter Grainge]

Initially I saw a topic titled Add Edit Products, then it switched to the default topic. I hit refresh and got the same again. I have not seen it do that before. Have you got some sort of redirect in Add Edit or some javascript doing something unusual?

First move try moving the Add Edit topic so that the path is short. I don't think that is it but it's worth a try.

Then try the method with a test project and some very simple topics.

Post back how that goes.

[Helen3308]

Hi Peter,

I put a testing page on the same directory as the default topic, so the Path is short, but the problem is still there 😞

It loads the topic first, and then redirect to the default topic.

Helen

[ewriter]

Hi all,
When I click on the TOC link to that page in Firefox, the address bar contains the entire html for the page, beginning with the stuff below. Looks as if there is some corruption or the source file has generated output.

Address bar content beginning:

[data:text/html;charset=utf-8,<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " http://www.w3.org/TR/html4/strict.dtd"><html><head><title>Chart of User Guide</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8">]

Address bar content ending:

[div>&lt;/body&gt;</div>&lt;/html&gt;</pre><span style="color:#ffffff;">Real housewives write extensions.</span></body></html>]

[HKabaker]

There's a basic error in this string:

http://www.mcssl.com/netcart/webhelp/user_guide.htm#Learning_The_Software/Main_Menu_Text/Products/ad...

Don't specify the directory path to Add_Product.htm, because user_guide.htm knows where to find it.

So the string should be:

http://www.mcssl.com/netcart/webhelp/user_guide.htm#Add_Product.htm


This may be worth a try:

.....(directorypath)/myproject.htm?actionPath=#targettopic.htm.

e.g.,

http://www.mcssl.com/netcart/webhelp/user_guide.htm?actionPath=#Add_Product.htm

all one line, no space after ?

Harvey

[Helen3308]

The user_guide.html doesn't know where to find the specific topic, that's why I put the path in the url. It works fine on IE and previous version of firefox.

The 2 examples you created generate "Page not Found" error.
http://www.mcssl.com/netcart/webhelp/user_guide.htm#Add_Product.htm
http://www.mcssl.com/netcart/webhelp/user_guide.htm?actionPath=#Add_Product.htm

If I remove the following lines from header, the topic will stay, but I cannot use the navigation and synchronize topic without those javascript files. Does anybody have the same problem?

<script type="text/javascript" language="javascript1.2" src="../../../whmsg.js"></script>
<script type="text/javascript" language="javascript" src="../../../whver.js"></script>
<script type="text/javascript" language="javascript1.2" src="../../../whproxy.js"></script>
<script type="text/javascript" language="javascript1.2" src="../../../whutils.js"></script>
<script type="text/javascript" language="javascript1.2" src="../../../whtopic.js"></script>

[Peter Grainge]

Harvey

You've lost me by removing the path from the startpage to the specific topic required for a CSH call. I've always used the method on my site which necessitates using the path from the start page to the required topic and nobody has ever told me that is wrong.

Helen

Can you please try this with a simple project as requested? Just a few topics and simple content.

[HKabaker]

It works fine for me in Firefox 2.0.0.1.

I've made some patches to help alternative browsers load the toolbars, TOC, and hide symbol; to fix a reload problem, and other things. I don't know if they affect the link with the # in it.

Backing up to the RH project, I assume the target topic and directory structure were generated in RH. In other words, there's nothing that RH might not know about.

Another thought, and forgive me for asking, but I have run into this problem myself:

Do the upper and lower case characters in the link match precisely with the target directories/files?

What about file names with no underscore?

Harvey

[HKabaker]

You say it loads the correct topic then reloads to the default page?

This sounds familiar.

Harvey

[Peter Grainge]

Let me repeat a tale I have told before on these forums. I used to commute with a forensic scientist and he taught me a lot about problem solving.

You are working with a project which we know has a problem. Putting a test page into that environment is not scientifically clean. We need a pure project. It may prove to be a waste of time or it may prove the problem is your project, not the call.

Up to you.

[HKabaker]

I agree with Peter's obervation about test projects.

Let me suggest some patches. They may cure the load-topic/reload-default-topic misbehavior.

In the output file whtbar.js look for this line:

else if(sType=="hide2"&&(!gbNav4)&&(!gbOpera))

It occurs only once. Change it to

else if(sType=="hide2"&&(!gbOpera))


In the same output file, near the end, look for

function tryReload()
{
if (gnRE==1)
document.location.reload();
gnRE--;
}

Make it read

function tryReload()
{
if (gnRE==1)
// document.location.reload();
gnRE--;
}

About those JavaScript references you were deleting, you need to keep them because they have browser-sniffing and filtering code.

Also:

In the output file myproject.htm look for these lines near the beginning:

<meta name="description" content="WebHelp 5.50">
</head>

Delete </head> here because it belongs elsewhere.


In the same output file myproject.htm look for these lines near the end:

</script>

<frameset cols="100%,*" frameborder=no border=0>

Make them read

</script>
</head>
<frameset cols="100%,*" frameborder=no border=0>


At the very end before </html>, insert <body></body>:



<body></body>
</html>

Why, you may ask, would Firefox be affected by code that filters for Nav4?

I don't completely get it, but it seems Firefox also identifies itself as a Mozilla browser, and the ancient code in whver.js appears to equate Mozilla with Nav4. Once this flag is set, it is not turned off. In fact browser ID flags accumulate. So Firefox may be burdened with RH browser ID flags for Mozilla, Nav4 and maybe Nav5, Nav 6, Nav61 and Nav7.

Just try to find your way through all the RH code filters with those flags.

If you're really adventuresome, go into whver.js and add flag definitions for gbFirefox (I think gb stood for generic browser, i.e., not IE) and insert it into all the "if" conditions where you think it should be treated the same as, or differently from, the other browsers.

Disclaimers and warnings:
All of the above applies to RH 5 code. I haven't had time to look in RH6. Adobe may have fixed some, not others.

Because these are output files, RH probably will overwrite them when you publish a revised version, so you must check the new published output.

As always:

It works for me but may not work for you; back up everything, test and retest, etc., etc. My driver's license is good in my chair but may not be valid elsewhere.

Good luck.

Harvey

[Helen3308]

Hi Harvey,

I tried your method, it doesn't work.

On each topic page, robohelp add the following javascript code.

if (window.setRelStartPage)
{
setRelStartPage("../../../user_guide.htm");

autoSync(0);
sendSyncInfo();
sendAveInfoOut();
}

If I comment out setRelStartPage("../../../user_guide.htm"), the topic will stay. Do you know what is that function do? It locates in whtopic.js - function setRelStartPage(sPath)

Thanks,

Helen

[Guest]

Hi Harvey

This is my first post on this forum. I am a technical writer for a small software development company. We are still running RoboHelp for FrameMaker (RHF) to produce WebHelp, which overall has been great for us. We are experienceing similar firefox issues in that our application links via URL to a context-sensitive help topic briefly, but then the topic is immediately replaced by the parent topic. (IE and Netscape work fine). I don't think RHF gives me a way to manually remove links between books and their default topics (as suggested by AuthorAnne in another thread). I tried your patches a couple of times; Even though they were only meant for RH 5 code - I still found each location in the code that you mentioned. This does not seem to help though.

Does anyone know whether the newly released RH 6 has eliminated this firefox issue? I have searched tech notes, forums, blogs, etc. to try to find out but no luck. We want to move to a supported Help software, but I am not interested in RH 6 if the firefox issues still remain.

Thanks, Barb

[HKabaker]

Sorry I missed this last week. I saw an empty message at one point and didn't go back.

I've noticed that code, but I don't know what RH is doing here.

Is there an "if" filter in front of it, or do all browsers come through here?

I'm guessing that this is where they reference the start page and use it for subsequent calls using # to drill down. If that's the case, why do we need to supply it in the link?

Another thought: Maybe it's used for the reload function, which may explain why some browsers always go back to the start page, while IE (I think) reloads the current topic.

I'd look for RelStartPage elsewhere in this js or any RH output file to see how it's used.

But it's interesting that this may solve the problem.

How does it work if you leave the Help window open, go back to the main app and navigate to another page, and click Help to bring up another topic in the same help window?

Let's start with IE and check Firefox later, if you will.

Thanks.

Harvey

[HKabaker]

Helen,

I have an answer for your most recent question:
""""""""""""""
On each topic page, robohelp adds the following javascript code.

if (window.setRelStartPage)
{
setRelStartPage("../../../user_guide.htm");

autoSync(0);
sendSyncInfo();
sendAveInfoOut();
}

..... Do you know what that function does? .....
"""""""""""""""""""""

This tells the browser where to find the launch file when it has to load the frameset from the "Show" command in a standalone topic.

For example, suppose topicA.htm is in the WebHelp package help.htm.

When you open help.htm, you see the default topic with the TOC frame and WebHelp toolbar. The TOC contains a link to topicA.htm.

When you open topicA.htm directly, you should see the topic by itself -- no TOC, no toolbar. If you have chosen "Show Navigation Pane Link in Topics," there is a "Show" text link or custom button. When you click the link, the browser looks for RelStartPage which, in this case, is help.htm and supplies the browser with the path

help.htm#topicA.htm

So if you block this bit of information, you disable the "Show" function.


Harvey

[HKabaker]

Barb,

Sorry, but I don't know anything about RHF and book-topic links.

It would help us to understand your problem if you would be more specific about how you are calling the topic, what you expect to see (topic only? frames with specific topic displayed?), and what you see. Also, is a help window already open but displaying a different topic?

(By the way, Firefox gave me an update to V 2.0.0.2 today.)

Regards,

Harvey

[Guest]

We are calling the topics from our app with URLs, e.g. "...../Help/index.htm#search_for_a_batch.htm". IE will display the topic "search for a batch" (with toolbar and navigation pane and synched toc). Firefox will display the topic "search for a batch" for a split second, then immediately change the display to the parent topic "searching the database" (with toolbar and navigation pane and toc synched with the parent). It is possible for another browser window to still be open from a previous Help call - several could be open at once, i.e. in IE7 several tabs could be open.

Note that today I have been testing this with the trial version of RH6, replacing the URLs in both firefox 2.0.0.2, and IE 7.0.5730.11. Assuming that local testing on my desktop is a fair test, the anomaly seems to be gone now in RH6.

However, if we knew how to patch this anomaly in RoboHelp for FrameMaker, we might hold off purchasing new software for a while longer while we continue to evaluate.

Thanks, Barb

[HKabaker]

Barb,

I think the patch in whtbar.js takes care of this in Netscape and Firefox, because it eliminates the reload. Have you made this change in the output file (near the end of the file)?

Harvey

[Guest]

Hi Harvey

I modified the line in output file whtbar.js as you suggested, but the reload is still happening in firefox 2.0.0.3 (I installed recent firefox update this morning). I ensured that there are no caching issues obscuring my results.

I notice when viewing the source of my reloaded output HTML file, a reload has been generated at the top of the file (see top of file below, 3rd line from bottom). I also searched on the reload text and noticed a group of other output files with reloads (other than whtbar). Do you have any other suggestions at this point? Thanks, Barb

code attached

[Guest]

Note one more observation: If I leave whtbar.js unchanged, and simply comment out the last line of whtopic.js so that it reads

else
// document.location.reload();

then the correct topic displays in firefox, without being replaced by the parent. However, the TOC remains unexpanded and no TOC synch takes place. In IE the TOC synchs up with the topic. Once whtopic.js has been changed, also changing whtbar.js still does not seem to affect anything.