Error 'this.node.parentNode is null or not an object' with search highlight in certain topics

[Casper_Lange]

goto http://www.afas.nl/profithelp/2_8_2/SE/index.htm
Click 'zoeken' (search)
Be sure that 'Zoekresultaten markeren' (search highlight) is checked
Type 'activa'
Click the topic 'activa'
An error is displayed in the bottom left corner: 'this.node.parentNode is null or not an object'
If search highlight is not used, the error is not displayed.

Any ideas?

[Peter Grainge]

With Highlight selected I don't get the error message.

I get one topic listed "Bezig met zoeken..." but there is something wrong as there is no link to the topic. Maybe seeing the topic I get will help you identify the problem.

[Casper_Lange]

Thanks for trying to help us, Peter. We are currently uploading a new version of our help. Sorry for the inconvenience. I will come back to you when everything is uploaded.

[Casper_Lange]

The helpfile is online again. The error is reproducable now.

[Peter Grainge]

Same result as before.

[Peter Grainge]

To correct...

Same result as before IN FIREFOX.

In IE7 I get a long list of results with links that work. There is a message in the status bar "Done with errors on page" but I've seen that before and it does not seem to have any impact.

Is this a merged webhelp output or a single project?

[Casper_Lange]

Well, maybe a caching issue on your side?
When I follow the steps above I get a list of topics containing the term 'activa' with no errors. This morning we had an error on the search page as well, but this was repaired.
If I click the topic as mentioned, i get the strange error.
This is not a merged project, but a single project.

Could you please try again?

[Casper_Lange]

And indeed, the error does not show up in a messagebox, but this is due to a setting in IE7. If people change this setting the messagebox pops up.

[Peter Grainge]

Not a caching issue as when I test things like this I always force a page refresh.

You said earlier "The helpfile is online again. The error is reproducable now" and I tested then but you now seem to be indicating that test was after the repair.

Also the error message I got, which did not seem to prevent anything working, was in the status bar but you are referring to a message box. Haven't got time to go through all the settings.

If you are now happy all is OK, fine. Otherwise please clarify what you want done.

[Casper_Lange]

OK Peter, I am very sorry and absolutely do not want to consume your time for nothing.

We show the Webhelp in our software in a special window, not in an IE7 window. In this window people cannot disable the popup. So they press F1 in our software and the special help window comes up, showing the online content.
Here they start seraching and then they get the error, which you can see in the status bar.

So my question is, have you got any idea:
- if this is a common error from RH7
- where this error comes from
- how we can work around this.

And again, I very much appreciate the time and effort you put into the replies to all the topics in this forum!

And please read through this stupid 'Topmanager' before my name. I hate this too. Adobe is busy to delete this from my accountname.

[Peter Grainge]

No apology needed, it's just that we didn't seem to be at one.
I think perhaps the difference is you are reporting a problem you see in the special window which of course I do not see. Do you see the same problem if you follow the same procedure just opening the help in IE?

[Casper_Lange]

Yes I do, when you open the error message that you see in the status bar you see the text that I posted above: 'this.node.parentNode is null or not an object'

[Peter Grainge]

I think the elves are at play here.

I unintentionally opened your help in Firefox and this time when I searched, I got a full list of results that worked correctly, no errors. Then I repeated that in IE and again, no errors! I just get Done in the status bar and it works as it should.

When you generate, do you have the WebSite or Local option selected in the third page. Try local and see if it makes any difference.

[Casper_Lange]

Okay, I will try that.

If you have the list of topics, containing the word 'activa', and you click on the topic 'activa' in this list, do you get the error in de status bar then?

This is when I get the error in IE7 (in our special window our users get this error in a popup)

[Peter Grainge]

If you have the list of topics, containing the word 'activa', and you click on the topic 'activa' in this list, do you get the error in de status bar then?
****************************************

Yes. Apologies, I had missed that final part.

Yes I have seen the Error on Page in the status bar but it has never affected functionality.

Identify a good topic in both source and output. Compare that with this one and see if you can identify any difference before the body of the file.

[HKabaker]

Does this happen for other terms, such as searching for "reports" and coming up with a list of topics including one titled, "Reports"? In my test, it worked fine for "reports."

If activa is the only case, I'd focus on the topic itself, in the search-term database files in whxdata and whdata, and in the project CPD database tables.

A longshot: what is the filename for the topic "activa"? How does the title appear in the <title> .... </title> line of source code?

If activa isn't the only case, I'd be looking at some js code, but I'm not sure exactly where, off the top of my head.

Harvey

[HKabaker]

After a little more digging:

this.node.parentNode

Appears three times in whtopic.js, which writes bread crumbs and
puts highlighting into topics found by Search. It's in the text highlighting funtion.

We're onto something here, but I'm not 100% sure what it is.

I'd lay money on some odd character in the topic title, TOC title, filename, the search term itself, or anywhere in the offending topic. Do you use en dashes or em dashes anywhere?

I ran into something similar where a Windows character & got garbled into &amp; for example. Also susceptible are &endash; and &emdash;

Did you select the UTF-8 character option, or Windows characters?

Harvey

[thismajorsea]

Hello,

I recently encountered this same issue with a specific topic in my WebHelp output from RHv7. Like the instance reported in this thread, the "this.node.parentNode" script error appears when you perform a keyword search and click on the topic name from the list of search returns. The strange thing is, this topic was in the Help system for our previous release, was not touched or edited in any way between releases, and DID NOT throw this error in the previous version. The only distinct change between versions that might have affected this topic was that we upgraded to RHv7 from v5 and compiled the Help for the recent release in v7.

Based on HKabaker's findings and recommendations, I searched the whtopic.js file for both outputs and found only one instance of 'this.node.parentNode.' in the whtopic.js file in the newer (v7) output. I don't understand JavaScript, so I'm not sure of the significance. Here was the block of text/code:

var spanElement = document.createElement( "span" );
spanElement.innerHTML = strHTML;
this.node.parentNode.replaceChild( spanElement, this.node );
if(gnYPos == -1)

I noticed no odd characters in the topic title or filename (there is no TOC entry for this topic).

Just thought I'd share. I have yet to find a resolution for this.

Todd Richardson
Windows XP | RoboHelp 7

[Captiv8r]

Hi Todd

Just thinking out loud here. Do you have Breadcrumb trails enabled? Because these are normally created based on the TOC path and you say the topic isn't part of the TOC, I'm wondering if the issue is related to Breadcrumbs. These are also new to version 7 and weren't part of X5.

Perhaps try generating with the Breadcrumbs turned off and see if that changes things?

Cheers... Rick

[HKabaker]

Rick,

It makes sense. This code comes into play only for breadcrumbs, as far as I can tell. Each topic has a little snippet of code referring to its path in the TOC, just for breadcrumbs display. If you don't use breadcrumbs in generating output, RH simply ignores the TOC information in the topic.

Sounds like the code doesn't have an escape hatch when it can't find the TOC path inside a topic.

Todd, a quick test, please: Give the problem topic a TOC page, just to test this notion. It might help Adobe fix the bug.

You shouldn't have to sacrifice breadcrumbs, if you really want them, and you shouldn't have to build your TOC around them, either.

Harvey

[thismajorsea]

Great information. Thanks.
I'll try this test and will let you know what comes of it.

Todd

[thismajorsea]

Breadcrumbs are enabled (I prefer to use them), but the offending topic does not feature a breadcrumb trail. Is this due to there not being a TOC entry for the topic?

What's interesting is I just encountered the same script error in another topic - one which does have a TOC entry and does feature a breadcrumb string. This seems to conflict with idea that breadcrumbs might be the cause. I'll continue to look into this, though.

Thanks again for your input.
/Todd

[thismajorsea]

Update:

I added a TOC entry for the first offending topic (which did not originally have a TOC entry, and no breadcrumb trail), but the script error still appears when you search for and click on the topic link in the search results pane. However, the error is not encountered when you select the topic from the Contents pane.

I also tried disabling the Breadcrumbs option in the project build properties, but the error was still encountered in the output.

It appears that this is caused by something in the search routine, and is not limited to breadcrumbs as first thought. Was the search routine enhanced or changed in any way between v5 and v7?

Thanks for your help so far.
/Todd

[HKabaker]

I think I have it, but it's almost unbelieveable.

In the activa topic, the word is highlighted up to a point. Coming to the next instance of activa, you have this code:

<li class=p-BulletedList><p class=BulletedList><b><span style="font-weight: normal;">V:</b> v</span>aste activa waarop wordt afgeschreven (Dit is de standaard waarde) . . . </p>

Note the superfluous <b> and </b> tags, especially with the <span> calling for normal font-weight.

Suppose this is a valid string. Because the opening tags are
<b><span . . .>,
the closing sequence should be
</span>...</b>

I'm not sure exactly why the error does what it does.

Perhaps this is a simple html error that happens to come in an awkward place, or
Because the browser expects </span> first, it treats </b> as text, so the <b> never gets closed, which confuses the search highlight script.

I've run into something like this before. Repeated application, changes and deletion of font attributes in approximately the same place sometimes results in confused tags. Similarly, when you apply a build tag to styled text, and perhaps change the font attribute, opening and closing tags get confused. It may depend on the precise locations where you started and ended your highlights during editing.

You'd expect this to be a harmless html error, but in this case, it breaks the highlight code, I believe.

You're in a better position to test this than I am, so I await your results.

Harvey