Search hangs in IE

This forum is for all Flare issues related to the HTML5, WebHelp, WebHelp Plus, and Adobe Air Targets
Post Reply
rglassman
Jr. Propeller Head
Posts: 3
Joined: Wed May 17, 2006 7:23 am

Search hangs in IE

Post by rglassman »

Hello,

When I open my WebHelp project (generated with Flare 4.2) in IE 7 and click the search tab, the search does not load. The search loading bar appears half full and it just hangs there forever. This is particular to one project. If I open another project in that same version of Flare and I use the exact same Target settings and Skin (just different page content), the search works just fine.

I am currently chunking the database. It doesn't matter if I change the chunk size. It doesn't matter if I turn chunking off. I tried using the SQl search option instead and it does not change the outcome. It works fine in Firefox as well. IE does not display any errors.

Any ideas?

Thanks,
Rebecca
You do not have the required permissions to view the files attached to this post.
rglassman
Jr. Propeller Head
Posts: 3
Joined: Wed May 17, 2006 7:23 am

Re: Search hangs in IE

Post by rglassman »

Update: If I open this project in version 3 the search works, but of course it breaks other work I did in 4.2. So, there must be something particular to this project in 4.2 that doesn't not involve the skin.
rglassman
Jr. Propeller Head
Posts: 3
Joined: Wed May 17, 2006 7:23 am

Re: Search hangs in IE

Post by rglassman »

IE error reads
Line 1295
Char: 6
Error: Object Required
Code: 0
URL: skin/search.htm in the output directory

There is no line 1295 in that file, so I presume it's a problem in the javascript, but I don't know which javascript file is the culprit.
TheGreatAndPowerfulOz
Sr. Propeller Head
Posts: 131
Joined: Mon Apr 24, 2006 12:52 pm
Location: Glen Mills, PA

Re: Search hangs in IE

Post by TheGreatAndPowerfulOz »

I am seeing the same symptom in Flare v6.1.0, though I hadn't ever seen it in any previous versions of Flare. Everything works swimmingly in Firefox and Chrome, but I get the following error with IE:

Code: Select all

Message: Object required
Line: 1933
Char: 1
Code: 0
URI: (my project path)/Content/SkinSupport/MadCapAll.js
I would normally just chalk this up to another lame issue with IE and walk away, but our web-based application requires our users to have IE 7+, and therefore I need to display my WebHelp in IE, as well.

As I examine the 'MadCapAll.js' file, I find the following code in lines 1924 to 1933:

Code: Select all

var propertyNodes=styleClassNode.getElementsByTagName("Property");
var propertyNodesLength=propertyNodes.length;
var propertyNode=null;
for(var i=0;i<propertyNodesLength;i++){
if(propertyNodes[i].getAttribute("Name")==propertyName){
propertyNode=propertyNodes[i];
break;}}
if(propertyNode==null){
return value;}
value=propertyNode.firstChild.nodeValue;
In an effort to figure out what might be going on, I threw an "alert(value);" line in just after the last line, above, and the following results came up in succession in the alert dialogue:

"Thank you for submitting your rating!"
"none"
"Verdana"
"8pt"
"#000000"

I wonder... might the "none" result have something to do with the "Object required" error coming out of IE?

The fact that the error occurs in conjunction with what looks like Flare's topic rating functionality ("Thank you for submitting your rating!") leads me to suppose that there might be something in that area. Now, I must say that we are not employing the topic rating functionality in our Help system, so I really don't know a thing about it...

For the information of anyone who might be willing to take a stab at helping with this issue, I know the following as regards the "alert()" results I listed above:
  • - "Thank you for submitting your rating!" shows up as the value for the RatingSubmittedMessage property for the ToolBarItem > TopicRatings style in my Skin's "Styles" settings
  • - "Verdana" is the font I've set to use for my TOC, Index, Search and other accordion contents.
  • - "8pt" is the point size I've specified for all accordion contents.
  • - "#000000" is the color I've specified for all accordion contents.
Austin Wright

Flare 2022 r3 (18.2.8431.26678) :: TopNav HTML5 / PDF output
TheGreatAndPowerfulOz
Sr. Propeller Head
Posts: 131
Joined: Mon Apr 24, 2006 12:52 pm
Location: Glen Mills, PA

Re: Search hangs in IE

Post by TheGreatAndPowerfulOz »

So, I tried creating a brand new project using Flare's "empty" template and generating some WebHelp output. When I tried to use the Search functionality in the output, everything worked fine—even in IE. Hmmm...

I tried a few changes in my real project (removing search filters from the project, removing references to my custom JavaScript, etc.), but to no avail... The Search functionality continued to hang.

Then I did a little tooling around in the "MadCapAll.js" file (the "source" file found in C:\Program Files\MadCap Software\MadCap Flare V6.1\Flare.app\Resources\WebHelp\Content\SkinSupport\).

First, I simply commented-out the offending line 1933:

Code: Select all

// value=propertyNode.firstChild.nodeValue;
The result was that —voila!— the Search worked in IE!

But I figured that line 1933 must have some reason for being, so I went through my output and tried clicking all sorts of different built-in Flare stuff. When I began clicking through some topics in my project's Browse Sequence, I noticed that the "Page n of nn" (CurrentTopicIndex) Toolbar element didn't work. OK... getting closer... apparently line 1933 has something to do with Browse Sequences (?).

So, I went for a conditional statement, to effectively skip line 1933 when the Search pane is loaded, but execute it when any other page is loaded.

I found a uniquely ID'd element in the source of the Search page ("SearchResults"), which I used to determine whether or not that page is currently loaded. Here's what I came up with to REPLACE line 1933:

Code: Select all

if (!document.getElementById('SearchResults')) value=propertyNode.firstChild.nodeValue;
Yeah... It's quite the kludge, I know, but it works!

I don't have the energy to tinker or troubleshoot this anymore, so I can't be certain whether the issue may have something to do with my particular setup, or if it's actually a general bug that MadCap may need to work out. I think I'll submit a bug report on it to see what feedback I get.

If anyone else has this issue, I hope what I've offered here helps just a little! :-)
Austin Wright

Flare 2022 r3 (18.2.8431.26678) :: TopNav HTML5 / PDF output
Post Reply