IE crash following intensive index use

[gimkrak]

I created a small WebHelp project (95 topics) using RH 5.x. When I launch the project in IE (6.0.x) and try to use the compiled index, I find that clicking quickly on 6-7 entries in a row causes the browser to shut down. I can click all day, slow or fast, in the same index using Netscape or Firefox, without incident. Any thoughts on a possible cause? This sounds like the same problem that Bin.Chen reported on 9/27/06. That post generated no follow-ups so thought I'd risk a repeat.

[maaf82]

I have the similar problems. Does anyone have a solution to this?

[HKabaker]

maaf82 (Welcome to the forum!) and gimkrak,

Might be something with how the browser loads the index at runtime from its database, which has its own housekeeping index in one or more files, pointing to keywords and definitions in one or more separate files. Each click of an Index term triggers a navigation pane reload.

The key, I believe, is response time from the servers. If it's a little slow or intermittent while IE is loading and reloading Index segments, the browser breaks down.

To test this, generate WebHelp optimized for local (LAN) network and again, optimized for Internet (Web). One output package will have more files in the whxxxx directories, breaking the Index into smaller chunks.

An added factor, I believe, is that RH creates a set of TOC, Index and Glossary files for IE, and a different set for Netscape/Mozilla/Firefox browsers. WebHelp invokes a browser brand sniffer from time to time and routes the browser to the appropriate javascripts and database sets. This accounts for IE not working the same as the others.

If you find that IE runs better with LAN optimization than with WEB output, or vice versa, check Firefox and Netscape again.

If the optimization setting makes no difference, please post back. I can suggest some easy code fixes that may smoothe out navigation pane loading in your environment.

Harvey

[maaf82]

HKabaker

Thank you so much for your quick reply. But i tried to generate webhelp optimized for local PC or Intranet, and i still had the same problem. Is there anything else i can do to make this work?

[HKabaker]

Hi,

I can get back to you next week.

Meanwhile, anyone who knows about this should jump right in.

Harvey

[maaf82]

Thanks Harvey. I look forward to hearing from you or anyone else that has a suggestion.

[gimkrak]

Hi Harvey, I just tried your suggestion for generating while optimized for local (LAN). Didn't seem to make any difference. Still seeing the same behavior in IE (crash following rapid sequence of clicks on index entries) vs. other browsers (tried Opera this time too, and like Firefox and Netscape it held up fine under the barrage of clicks). I'd very be interested in the info. you have about code fixes that improve nav pane behavior. Thanks for your help.

[HKabaker]

Based on errors in html syntax reported by a code checker, and
From research on what ails the WebHelp toolbar and navigation pane,

Code revisions I have made over the past two years in WebHelp output files are attached
here.

An experienced js developer might say some don't accomplish anything, and I wouldn't
quibble. Over time, though, I've seen some real improvement for WebHelp in IE and other
browsers.

Some of these files have templates in the RH directory:
Program Files/RH Office/RoboHELP/WebHelp5Ext

Where possible, I have patched the templates to get the head and body tags where they
belong. The really important ones are in the WebHelp output package.

Generally, these are fixes for Firefox, Netscape and Opera browsers because the
original output seems to work fine in Internet Explorer.

However, I think IE does notice some of these irregularities and takes just a little time to decide to ignore them. Most of the time you wouldn't notice. But if you are loading and reloading the Index (or Glossary, or TOC if they are long) several times in quick succession, and the browser just quits, maybe these patches will fix that.

I can't swear to the need for all of these changes. But they seem to do no harm either, so I haven't taken time to remove any for more testing. Those that seem most important are at the top. If I were to start from scratch for the Index, I'd try

whtbar.js
whibody.htm
whidhtml.htm
whgdata/whnvl31.htm
whgdata/whnvl32.htm
whgdata/whnvl33.htm
whskin_mbars.htm and
whskin_tbars.htm

Good luck, and please post back.

Harvey

Almost forgot:

Results not guaranteed; back up everything; it works for me but I can't promise; yadayadayada.

HK

[maaf82]

Hi Harvey

I tried the code fixes that you suggested but it still didnt work. Everytime i made changes in the code and then published it, it would revert back to the intial code. IE is still crashing when i click items in the index. Do you or anyone else have any more suggestions? I will gladly try anything to make this work.

Thanks!

[Peter Grainge]

In your original post you said "I find that clicking quickly on 6-7 entries in a row causes the browser to shut down. I can click all day, slow or fast, in the same index using Netscape or Firefox, without incident. Any thoughts on a possible cause?"

The sarcastic answer would be "Yes, clicking 6-7 entries in a row causes the browser to shut down so don't click so quickly." :-) What hasn't been asked is whether the speed of clicking on one after the other is realistic. Is it just you testing something a user would never do or are you clicking at a truly representative rate?

Have you opened the help from another PC? Does that have the same problem?

[maaf82]

The speed i can clicking in is the same speed anyone would use when clicking on items in the index. it is neither too fast or too slow. i did try opening the project on another computer and the same problem happened. i asked another person to test it on their computer and it still crashed.

[gimkrak]

Hi Harvey, thanks very much for your code fixes. On early testing, they seem to improve the speed of page loading. Sadly, like maaf82, I must report that the fixes don't seem to address the IE crash problem. As before, IE still crashes following a rapid series of clicks in the index list, while Netscape, Firefox, and Opera hang in there.

Hi Peter, thanks for your input on this. Good point. The IE crash behavior was originally noticed/reported by one of our QA testers (working on another PC). After reproducing the problem on my PC, and then being unable to change/correct it, I'm assuming that what I'm still seeing is what the QA tester would continue to see as well. But I will retest again myself on another PC. As for how 'real-world' likely the behavior is (users accessing index entries in a rapid sequence, causing the IE crash), I don't know. The thing that mainly bothers me is the diff. response of IE from the other browsers. In the case of other WebHelp browser-based issues I've had, non-IE browsers seem to be the ones acting up. This is the first time I can recall having a problem on IE and NOT having it anywhere else.

Until my QA group flags it as a major problem, I'm not going to consider it as one. But I would still like to find a solution for it.

[Peter Grainge]

You can break many programs by doing unrealistic things. Do your testers also pour coffee over the keyboard and then complain it doesn't work? To be more serious, this is not an oft repeated problem so I don't think you will get adverse reactions from real users.

[Peter Grainge]

There has to be a reason why you guys are having this problem, obviously. Harvey suggested server response time and that does look like a likely candidate. If you generate the help to your hard disk and then do the same things with the index, do you then have the same problem?

[maaf82]

Peter,

I am generating the help from my hard disk and i had another person generate the help from their computer and IE still crashed on us. I am clicking at a normal speed and it still crashes.

[gimkrak]

Peter, you're probably right about this not being an oft-repeated problem. At least in my case, the required stimulus is a series of rapid (almost spastic) clicks. However, sounds like maaf82 may experience the IE crash after more normal/common clicking on index entries.

Again, at least just in my case, server access doesn't seem to be involved. The QA tester who first pointed out the problem to me was accessing the Help over a server connection, but I am not. I'm accessing the Help on my hard drive.

[Peter Grainge]

Yes but are you generating an output TO your hard disk rather than the server that will ultimately be used. My thinking is that if the problem occurs only when the help is accessed from the server but not when you access an output on your hard disk, you have confirmed Harvey's suggestion that the network response times are kicking in.

[maaf82]

I generated it from my hard disk and the sever, and it still crashes IE. If I select an item in the index and it displays the links related to it, and if i dont click on any of the links and click on the next item or any other item in the index it crashes. Once again i am doing this at a normal speed. I can click on an item and then select a related topic and keep doing this and it will not crash. but whenever i click on an item in the index and then click another item in the index and the related topics box remains open it crashes. Is there a way i can make this related topics box disappear soon, so it wont crash when selecting another item in the index without selecting a topic from the related topic box?

Thanks

[Peter Grainge]

Thanks gimkrak. That sort of rules out the thinking, at least in your case. I'll do some testing tomorrow on one of my projects.

[Captiv8r]

Hi Peter and all

For what it's worth, I just now tried this with a fairly large project on my local drive. I'm not sure how fast "spastic" clicking would be, but I did try rapid clicking. Unfortunately I'm not able to replicate the problem either.

Like Peter, I also wondered why anyone would ever see the need to rapidly click through the index. I mean, normally one clicks an entry, pauses to at least skim what is on the topic page to the right, then possibly clicking another entry. I cannot fathom why (unless someone is intentionally trying to induce an issue or is testing) someone would ever have a need to rapidly click from link to link to link in the Index.

Cheers... Rick

[HKabaker]

I agree that server response time is always an issue. RH has timeout/escapes in more than one location. Either they don't do what they're supposed to do, or WebHelp needs another timeout/escsape right here, or the problem is caused by the ones in the code now.

It stands to reason that anything we can do to eliminate an unnecessary chore will help the browser do its job faster. And that's better in all circumstances.

There is one more quirk that can slow down the nav pane (re)load.

By any chance, are you using a background image in the main toolbar -- repeat, main toolbar -- and do you see it repeating in the small toolbar (minibar) over the TOC/Index/Glossary?

Harvey

By the way, maaf82, did you install all the patches, or did you decide one or more are unneeded?

Thanks.

[maaf82]

Harvey,

I am not using a background image in the main toolbar and i do not see it repeating in the small toolbar (minibar) over the TOC/Index/Glossary.

I have installed all the patches.

Thanks

[gimkrak]

I am not using a background image in the main toolbar. In fact, I get the same error (IE crash immed following intensive index access) in WebHelp projects generated without a skin -- i.e., with the '(Traditional style - no skin)' option selected on the first page of the WebHelp compile wizard. And as with 'skinned' WebHelp projects, IE crashes but the other browsers do not.

[Peter Grainge]

I ran a test on a 12,000 topic merged webhelp project where every topic has at least one keyword. Nothing I could do would break it.

One last thought as I don't know what else to suggest, are your keywords stored in the HHK file or do you save them in the topics?

[maaf82]

Peter,

I save all my index keywords in the topics.