Search results redirect to parent in Firefox

[Guest]

Using RH7 WebHelp output viewed in Firefox 2.0.0.14 running on a Windows XP machine, both search results and index links redirect to the associated parent topic when clicked. That is, the landed topic is a book-level topic. (The books in my project link to HTML files.) Do I have to remove links from books to get search and index to function properly, or does anyone know of another workaround? Incidentally, functionality works as expected in IE; that is, it actually works.

[Peter Grainge]

Welcome to the forum.

When you say "landed", do you mean "linked"?

That problem has been posted before and the answer was to remove links from the books. Thought that had been fixed but not sure.

[Guest]

Thanks for the welcome, Peter. Yes, when I stated "landed," I meant the page that opens in the browser as a result of clicking a link.

I will remove links from books (which I do not want to do) to see if that resolves the problem, but it seems there must be a better solution since I'd like to keep the links.

If that's the only known solution, though, I guess I'll just have to settle.

[HKabaker]

Are you linking to the same topic from the book and from a page within the book? In that case, TOC sync will go to the book.


Harvey

[Guest]

Harvey,

I'm a titch confused by what you mean about "linking to the same topic from the book." I do have links from books, and there are pages within the book. I do not have the page that the book links to included as a page within the book; it is linked to the book only.

The behavior I've noticed is such that when I click a search result or an item in the index, the correct page where the search result or index item is located flashes on the screen but then immediately redirects to the parent page. I have automatic syncing enabled; when I view the contents, the topic that is displayed in the browser is synced in the TOC. Since the clicked link from search results or the index causes a redirect to the parent topic, I have noted that I can click the browser's back button and go to the correct page and the highlight in the TOC automatically syncs.

[HKabaker]

OK,

Your first message referred to the "associated parent topic." From the latest response, I gather that you are referring to the main default topic, the one that appears when you first open WebHelp from the launch file, myproject.htm.

As I understand it now, your search results and index keywords do open the appropriate topic, which is linked to a book, but the default topic immediately replaces it, as though you had clicked on its TOC entry.

Is that right?

Have you tried the Firefox 3 upgrade?
Have you installed the latest update for RH 7? If so, the "About" popup will show V 7.02.001.

Next: Is the default topic at the top of the TOC, standing by itself? If it's lower down -- by itself or inside a book -- try moving it to the top.

If that doesn't fix the problem, try removing one of the book links to a topic and insert a new TOC page for that topic. When a search result or index term opens the topic, does the problem persist?

Good luck.

Harvey

[Raven_Sati]

Harvey -

I am having this exact same effect - I am sure what CraigularGuy means is that when clicking a link in the search list it goes tempoarily to the correct page and them immediately goes to the page linked to the book that the link is in and he has associated the book with the first topic of the topics in the book)

I have Firefox 3 and have applied the latest updates to RH7 - (i am using winXP sp2)

It is still not working

Your fix (and Peter's - removing the link from a book) works for me - so thanks, sorta ...

However, If one cannot have book links and expect it to work in Firefox 3 (or whatever - books with links works fine in IE 6 & 7 for me with no search problems) then that is really annoying (along with the crappy choice of icons and skins)

I have the impression that Adobe doesn't really get that we are creating products that people look at and use rather than just work in the background and that appearance and smooth functioning are actually important - the ability to match the appearance of help to the program, site, or product makes a big difference in customer satisfaction - but Adobe doesn't seem to care about that either

Any Adobe people viewing this ? Comment ? Going to fix it someday ?

[Peter Grainge]

Your impression is way out. Since Adobe came on the scene, they have listened more to users like you and I than Macromedia ever did.

Follow this link and submit what you want. We have found putting it in a friendly way works. :-)

http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

[HKabaker]

What is the purpose of having the book link to a topic and a page within the book linking to the same topic?

Harvey

[MergeThis]

Raven Sati:

Contrary to your opinion, I don't think that Adobe is responsible for the Firefox decision, in their latest version that's been out a few days, to display things in a decidely different manner than IE. Netscape used to do that all the time, seemingly to get folks beating up on MS and Blue Sky (pre-Macromedia & pre-Adobe), so I guess Firefox is following the same business model.

Since Adobe purchased (rescued) RH from Macromedia, they've issued two full update versions (RH6 & RH7) and several patches. The Pre-beta2 Release What's New doc, dated 10/19/2006, called for better integration with Captivate and PDF, better conditional tags (for tables, TOCs, Indexes, etc), user-defined variables, command-line compilation, etc., etc., etc. Yes, I think Adobe gets it!

Have you been to the Mozilla forum to do some of your bomb-throwing there? I'm sure they'd love to hear from you...

Good luck,
Leon

[Harvey: I think that CraigularGuy specifically reported, on 6/26/2008 12:15:15 PM, that "I do not have the page that the book links to included as a page within the book; it is linked to the book only." ]

[HKabaker]

Leon,

I should have addressed my comment to Raven, who wrote:

I am having this exact same effect - I am sure what CraigularGuy means is . . . and he has associated the book with the first topic of the topics in the book).


Craig isn't doing this, but it sounds like Raven is.

I wouldn't get too angry at Mozilla just yet.

And we need to give Craig some time to respond to my requests yesterday for clarification.

Harvey

[Raven_Sati]

Peter -

Thanks for the link, I will use it

Leon -

Sorry to upset you (you work for Adobe ?) - I didn't think my attitude re frustrations I've had with using RH7 was really "bomb-throwing" (or I wouldn't have said anything) - but, point taken - I will only complain from now on to people who can do something about it, and, I'll be as diplomatic as possible as Peter suggests

[rwh86]

Hi Guys,

We have a huge project in robohelp (some 7100 topics). We are a publisher of medical guidelines, and this project is essentially an electronic version of our book series. We've been developing it in RoboHelp ever since late 2001, and we're currently using RH5, but we've also got a copy of RH7 that we're testing in pending switching over to using it.

We've had the exact problem that's been described here for at least the last three years, if not longer; it's present in both our RH5 and RH7 builds. Each time we do a release of our product (three a year) I try to find a solution, and this is the closest I've come despite reporting the bug several times, and even generating a minimal fileset that demonstrates the problem (I've not submitted a bug report since Adobe have taken the reins though so I guess they're off the hook ;).

The way it manifests itself for us is the same as what has been described in this thread so far. It's kind of subtle though, so I'll add my version to see if helps at all.

We call it the "Jumping TOC" problem. Essentially what happens is that the content frame and toc jump from a leaf topic back to its containing book. This occurs whenever the leaf is reached by some other means than clicking on the toc itself. So you could be clicking on a link in a topic which leads to another topic, you could click on a link from the index or search tabs. However you do it, instead of being taken to the topic that you expect, you are taken to its containing book. This happens so fast it's easy to miss it, which makes the DHTML toc unusable for us in FF.

Pretty much all of our books have topics associated with them, and they're different topics than those linked to by their child topics. The jump can occur whether the child topic you're trying to link to is itself a book or just a leaf topic.

Note that it only occurs when using the DHTML toc, not the Java or Plain HTML and it only happens with syncing enabled. Since the release of Firefox 3, we've come to realise that the Java toc isn't really an option for it; it's way too flaky, sometimes refusing to load entirely. So for our current relese, due out in a few days, I suspect I'm going to have to try modifying the javascript to add browser detection for specifically for FF3 and to use the DHTML toc for it, but also to disable toc syncing (but only for FF3). Neither of those things are particularly difficult to pull off and I can post the code changes if anyone's desperate.

Cheers,

Robert

[HKabaker]

A couple of immediate workarounds present themselves here, pending resolution by Adobe.

1. Don't sync TOC. OK, maybe that's unacceptable.
2. Remove links from books and insert a page (leaf) as the first topic in each book.
Is that unacceptable? Why? What's the more important here -- making the target topic "stick" when you've come from a Search or Index link, or preserving those book links to topics?

Robert, if you can develop an easy solution and share it with us, that's great! Maybe Adobe will pick it up and give you credit, if they can't afford to spend the time on fixing this.

Harvey