Announcement

**David** · Nov-02-2007, 11:46 PM

What we told Kevin (Virtual9) but he didn't make clear in his post was.

1) Having the highlight function skip sections of the page probalby won't resolve this issue.

In the incompatibility problems we have seen in the past skipping Zoomstop sections would *not* fix these kinds of problems. So this is not a solution in general. It is wrong to claim this is a solution. JS incompatibility problems are more typically duplicated variable names in different pieces of JS code or two scripts acting on he same 'object' in the JS object model in different ways. i.e. it is not the highlighting the is the problem (in general) it is the actual execution of the scripts on the same page.

2) OpenCube have heavily obfuscated their scripts (we don't do this). An example of their code is below. This makes debugging their work very very time consuming.

Code:

 
------EXAMPLE OPENCUDE MENU CODE------
if(!nt&&o.qmts){qm_si=o;qm_tt=setTimeout("qm_oo(new Object
(),qm_si,1)",o.qmts);return;}var a=o;if(a[qp].isrun){qm_kille(e);
return;}qm_la=o;var go=true;while((a=a[qp])&&!qm_a(a)){i
f(a==qm_li)go=false;}if(qm_li&&go){a=o;if((!a.cdiv)||(a.cdiv&&
a.cdiv!=qm_li))qm_uo(qm_li);a=qm_li;while((a=a[qp])&&!qm_a(a))
{if(a!=o[qp])qm_uo(a);else break;}}var b=o;var c=o.cdiv;if(b.cdiv)
{var aw=b.offsetWidth;var ah=b.offsetHeight;var ax=b.offset
Left;var ay=b.offsetTop;if(c[qp].ch){aw=0;if(c.fl)ax=0;}else 
{if(c.rl){ax=ax-c.offsetWidth;aw=0;}ah=0;}if(qm_o){ax-=b[qp]
.clientLeft;ay-=b[qp].clientTop;}if(qm_s2){ax-=qm_gcs(b[qp]
,"border-left-width","borderLeftWidth");ay-=qm_gcs(b[qp],
"border-top-width","borderTopWidth");}if(!c.ismove){c.style.
left=(ax+aw)+"px";c.style.top=(ay+ah)+"px";}x2("qmactive"
,o,1);if(window.qmad&&qmad.bvis)eval(qmad.bvis);c.style.
visibility="inherit";qm_li=c;}else if(!qm_a(b[qp]))qm_li=b[qp
];else qm_li=null;qm_kille(e);};function qm_gcs(obj,sname,
jname){var v;if document.defaultView&&document.defaultView.get
ComputedStyle)v=document.defaultView.getComputedStyle
(obj,null).getPropertyValue(sname);else
------END EXAMPLE MENU CODE------

3) We don't charge consulting fees to fix things that turn out to be bugs in our software.

4) We offered to sign a NDA with OpenCube an investigate the issue in their software for free if they provided non obfuscated code.

5) We dedicated half a page on our site warning people about the highlight script compatibility issues with 3rd party script and offering some solutions.

6) We have investigated similar issues in the past (with other 3rd party scripts) and the problem turned out to be in the 3rd party script.

7) The Zoom search function works fine on the same site as OpenCube, if you turn off the highlight option.

But if anyone does have a solution to using the highlight function with the OpenCube script, they are welcome to post some suggestions.

**opencube** · Nov-06-2007, 06:25 PM

bug in wrensoft highlight code

The issue here is not the opencube software or 3rd party scripts, the problem lies within the wrensoft highlight code.

I've done a simple test which shows the problem, the page below has a single div. JavaScript then applies a red color to the text in the div and an onclick event which triggers an alert. After wrensofts highlight code is run a blue color is applied to the div, or should be anyway.

Here is the working version.
http://www.opencube.com/wrensoft/working.html

Here is the broken version with wrensoft.
http://www.opencube.com/wrensoft/broken.html

The problem is that the wrensoft highlight function uses innerHTML to basically re-write the entire document. By doing this all the elements within the body are destroyed and re-created. Any global variables or functions which were applied to elments in the page before the wrensoft highlight function is called are also wiped out.

This isn't specific to the OpenCube menu, most 3rd party scripts do a alot of scripted setup with custom functions and global variable settings before the document loads, wrnesofts innerhtml highlight code wipes this out and essentially breaks 3rd party scripts.

Setting globals and element functions onload by 3rd party developers doesn't help iether as there is no guarantee to which order onload functions are called, in-fact OpenCube testing shows that attachevents and addeventlistners run in the opposite order, and some browsers call eventlistners before onload events which are applied directly to the body tag. The only plausible solution for a 3rd party fix to these issues is for all 3rd party scripts to execute on some delay timer after the documents onload event is triggered, which would make most 3rd party software very un-appealing.

Wrensoft's only solution is to rewrite the code such that it walks through the existing dom searching for matches, then indivividually applies the span tags which create the highlight effect, however even this will be problematic as the same issue will again arrise for text matches in a node with other child elements.

I'm not sure why your staff decided to pass the blame rather than doing a simple test such as the one I provided here. Maybe OpenCube should get into this type of software as we could probably offer a better solution.

-Jesse

OpenCube Software Developer

**Ray** · Nov-07-2007, 03:35 AM

Jesse (opencube), thank you for writing in and contributing to this discussion.

As we have mentioned and offered before, we would be happy to look further into this problem if we can be provided with the information needed. You may want to re-read our posts above however, as we have never blamed your script nor claimed that there was a bug in your script.

What we have stated, is that due to the obfuscated nature of your script (i.e. it has been intentionally made unreadable), we are unable to look into this problem further to determine whether this is due to a bug in your script (which is a possibility given that we can't see what's happening), or what the exact nature of the conflict is, to give any further advice.

Your posts brings to attention the nature of the conflict, but it is misrepresenting the cause.

Originally posted by opencube View Post

I've done a simple test which shows the problem, the page below has a single div. JavaScript then applies a red color to the text in the div and an onclick event which triggers an alert. After wrensofts highlight code is run a blue color is applied to the div, or should be anyway.

Here is the working version.
http://www.opencube.com/wrensoft/working.html

Here is the broken version with wrensoft.
http://www.opencube.com/wrensoft/broken.html

Here is a working version "with wrensoft" (note the apostrophes):
http://www.wrensoft.com/opencube/notbroken.html

And here is another one:
http://www.wrensoft.com/opencube/notbroken2.html

But all of the above examples are misrepresenting the problem. For our other readers, who have not looked too closely at the source code, the above examples from Jesse replace our entire highlight Javascript with this one line:

Code:

//simulation of wrensoft code, ...
document.body.innerHTML = document.body.innerHTML;

Your examples effectively demonstrate that the problem is related to the usage of the innerHTML property in Javascript (which is very true, and I will elaborate further below), but to simplify this as being "the wrensoft problem" is inaccurate, and ignores that there is essentially a conflict of functionality here.

That is, as demonstrated in my examples above, we can just as likely claim that using the innerHTML property is the primary functionality (and should occur first), and that your attempt to access a variable declared before it, is unsupported and "broken".

Originally posted by opencube View Post

The problem is that the wrensoft highlight function uses innerHTML to basically re-write the entire document. By doing this all the elements within the body are destroyed and re-created. Any global variables or functions which were applied to elments in the page before the wrensoft highlight function is called are also wiped out.

Agreed. This is the core of the problem at hand, and it is something we are aware of and have pointed out to previous users and script authors. We have, in fact, provided similar code examples as above in the past to demonstrate this, so we are pleased to see that we are on the same page here.

If anything however, this should be considered a bug in the browser's Javascript interpreter, since the contents of innerHTML was not removed or changed. It was, as your example above, assigned to an identical copy of itself. For webmasters and script developers, this behaviour of the browser needs to be considered and worked around accordingly.

Similar to your comments, we would need to point out that this problem is not specific to our highlight script, and that the OpenCube menus are consequently incompatible with any scripts which accesses the innerHTML property.

There is no blame to be casted on either side (although we are still simply presuming on the functionality and bug-free aspect of your script, since we can not actually look at what it's doing, while we provide our script unobfuscated and clearly readable so it is open for analysis).

Originally posted by opencube View Post

This isn't specific to the OpenCube menu, most 3rd party scripts do a alot of scripted setup with custom functions and global variable settings before the document loads, wrnesofts innerhtml highlight code wipes this out and essentially breaks 3rd party scripts.

Disagreed. Many scripts do not require initialization to occur before the document loads, and can be positioned or called at various points of the document as needed.

In fact, there are other DHTML popup menus which work well with our highlighting script as it is. This user for example uses our script with the Dreamweaver Popup Menus:
http://williamhawley.net/recordings.htm?zoom_highlight=christmas

Here is another user submitted example that uses Adobe GoLive with the MenuMachine plugin:
http://www.totaldiving.com/en/total/locationhours.php?zoom_highlight=location

Our script is designed such that it can be called at various places of the page. So in these example, it can be called before the menu code, because the DW menus did not have the additional requirements your script does.

Other functional examples would include CSS-only popup menus, such as this one from the Gibson Research Corp. which is offered for free:
http://www.grc.com/menu2/invitro.htm

Your product is advertised as "pure CSS", which (from what I've seen on your site) seem to mean that it will revert to a Javascript-free version of the menus, when accessed from a browser without JS support. Perhaps you have an option which allows the user to force it to always run in this mode? If not, maybe you could consider adding this option for the user to make the choice.

Originally posted by opencube View Post

Wrensoft's only solution is to rewrite the code such that it walks through the existing dom searching for matches, then indivividually applies the span tags which create the highlight effect, however even this will be problematic as the same issue will again arrise for text matches in a node with other child elements.

As you have already stated, this method has the same problem, so it is not much of a solution at all.

Originally posted by opencube View Post

Maybe OpenCube should get into this type of software as we could probably offer a better solution.

You are more than welcome to develop an alternative highlighting script. Our "jump to highlighting" script is provided free of charge, as an additional (and optional) feature to our search engine product. We do not sell this script in and of itself.

If your highlighting script provides better functionality, we would gladly recommend it to our customers should they require an alternative to the one that we provide.

**opencube** · Nov-07-2007, 06:56 PM

Thats alot of dancing around and I'm not going to point-for point such a long post, I will say...

The examples I provided use one innerhtml code line to illustrate the point in its simplest form. If you would like to modify the code examples to include your full source code you will see the exact same behavior.

Blaming our obfuscated code and not having access is silly, we don't give this out. When you ask microsoft because of there supposed innerHTML bug, they wont give it to you iether.

Bottom line, your customer contacted us, we provided them with a simple fix which did not have anything to do with the OpenCube code. I replied to your post in a blunt manner because I didn't care for the way you insinuated that the issue was with our software.

You can dance around the issue all day long with a whole book if you wish, in the end innerHTML is working as it should in the brwosers and your use of it is causing scripts like mine to fail. There is nothing I can do on my end to fix the problem except call my code after yours, which is the solution we gave your customer. If I expected other scripts to wait for mine to run first, I'd be out of business!

-Jesse

**David** · Nov-07-2007, 07:46 PM

We came to the conclusion that the fault was that both scripts expected exclusive access to the Javascript innerHTML object. In the absence of being to easily look at your code, the easy solution seemed to be to offer your customers the option of using your "pure CSS" option, or, as you suggested, change the script call order.

It you have made this solution available to your customer, then that's great. I think we can close the issue.

**opencube** · Nov-07-2007, 08:59 PM

Our script does not use innerHTML to change content outside of the menu, so my conclusion is quite different.

Yes the issue is closed, however, next time I need to fix one of your bugs which you insinuate is ours I will have to charge a consulting fee.

-Jesse

**David** · Nov-07-2007, 10:54 PM

We agree there was a conflict between the scripts, but not a bug in either code. You are entitled to your own opinion however.

For other users who are trying to get both scripts to work together, here is the solution that Jesse suggested and has since be confirmed as a working solution by the customer.

A change was made to the script call order,

Code:

<body onload="highlight(); dynamicMenu();">

And a new function was added, to call the menu script.

Code:

 
<!-- Create Menu Settings: (Menu ID, Is Vertical, Show Timer,
Hide Timer, On Click, Right to Left, Horizontal Subs, Flush Left) -->
<script type="text/javascript">
function dynamicMenu () 
  {qm_create(0,false,0,500,false,false,false,false);
</script>

Short of a major re-write to one or the other of the scripts, we agree this is the best solution.

We appreciate the time it took you to write this code. If we have customers that have similar issues with other navigation scripts we will suggest they have a look at your product, now that they are known to play together.

**Virtual9** · Nov-08-2007, 05:33 AM

As the initiator of this post, we believe we have an obligation to confirm that we now have a working solution using both OpenCube QuickMenu menu software and ZoomSearch search software on our company website. Problem resolved.

We think both of these products are leading commercial products that we expect to use, not only on our website, but on our client's websites. If you’re looking for best-in-class menu software, think OpenCube, the same goes for Wrensoft in the search software category.

Judge for yourself the technical merits of the above conversation regarding software development approaches. At a minimum, it is informative.

Thanks much to OpenCube for their diagnostic work and proposed solution, and to Wrensoft for their assistance in resolving this matter. At the end of the day, our general experience with both companies is positive and we shall remain as clients of both organizations. We can recommend both organizations to you.

A final comment from the perspective of a technology consulting firm . . . We believe the leading market position of these two companies requires them to help clients find a solution to the type of problem surfaced in this post. And they did. With that said, we do not expect either company to necessarily agree to diagnose or debug any obscure script found on the Internet, but again, when software from leading, reputable firms is involved, it is incumbent on all parties to put forth a reasonable effort to resolve matters – as they ultimately did here.

**opencube** · Nov-08-2007, 06:39 AM

We agree there was a conflict between the scripts, but not a bug in either code. You are entitled to your own opinion however.

A conflict intiated by wrensofts code, yes! Your code which is designed to re-write the page a second time after it already loaded destroys other scripts. Your assumption that you can use innerHTML to re-write the page whenever and at any time of your choosing is a major flaw and major bug in your software. You can twist it all day long, attempt to share the blame, blame the browsers, and even ignore your customers tech requests regarding the issue by blame shifting to OpenCube and other scripts, in the end your code kills the OpenCube menu and many others.

Your highlight runs, then re-writes the entire page for a second time, and you expect all other scripts on that page to work?? I would personally never dare or assume this kind of scripting would ever work. This is just plain bad judgement on your part, I undrstand the ego trip and why you cant be wrong on your own forums, believe me, I know, I have 3 kids whom pull this stuff. But you'r not children, why cant you just say... oops, I goofed and I'm working on a better solution, aren't we all adults here. Why do you have to come up with stuborn arguments against OpenCube who has nothing to do with this?

What really gets me is companies who don't have a clue about customer service. Check OpenCube's forums, we fix every single problem presented, we change the software when bugs are found, we workaround other peoples software bugs like wrensoft's without blame shifting, we give free upgrades if that fixes it, etc... We fixed this forums original posters issue because whensoft failed to do so and instead blamed the issue on OpenCube. Obfustcated or not, I find it sad that you used this as your argument for why you could not remedy an issue your customer was having with your software.

Come on guys, grow up and own up. I do appreciate you taking it down a notch and stating that its a shared issue rather than insinuating OpenCube is to blame. Lets move in the right direction and state that OpenCube's menu has nothing to do with the problem, and instead wrensofts highlight code is overwriting other scripts and needs to be updated.

-Jesse

**opencube** · Nov-08-2007, 07:02 AM

No offence here virtual9, I understand that you purchased and support both the OpenCube and Wrensoft software. However you started out by complaining heavily about wrensofts support, because of them wanting to charge you to fix the issue, etc....

Wrensoft then replied by basically stating the problem was with OpenCube for a litany of reasons and never offered you a solution.

I saw this post in google and some time after that you contacted our support staff. Garret in support mentioned it to me, I remebered spotting your post and personally dug into the issue.

Previously annoyed by the wrensoft post which shows up in Google, I gave it extra attention, regardless of that, garret would have resolved the issue in the same manner as we do for all OpenCube customers and fixed the problem for your.

I quickly found the issue to be wrensofts code, made examples, then replied in there forum in the same blunt manner which they insuated that the fault lied with OpenCube, this was for spite only as they were so quick to blame us.

Naturally, as I expected they gave a tit for tat and could not own up. I appreciate your post here, and I understand I will never win this argument with wrensoft as it's highly technical in nature, and most do not understand its foundation. However, it was OpenCube who fixed the issue for you, wrensoft had nothing to do with it, I personally problem soved this by weeding though there code to find the quark with there innerHTML whcih led to an email or post by garret giving the solution.

For personal spite towards wrensoft for attacking OpenCube i'd like it to be known they they did not ever acutally help you make the two scripts work together, rather OpenCube did. The only thing wrensoft has done is blame OpenCube in this post. OpenCube rebutted that blame and also fixed your issue when they could not.

-Jesse

**Ray** · Nov-08-2007, 07:53 AM

We have wanted to let this rest, and have tried our hardest to maintain our objectivity by focusing on the issue and the facts. You clearly have very different intentions, and are insisting on starting an argument. Why argue when the issue was resolved to everyone satisfaction?

I will point this out again, that we have never accused nor attacked your company or your product. The words are clear in the previous posts, and you can look over them again. Feel free to quote the text where you insist we have "insinuated" otherwise. All of our posts have been facts:

We were unable to look into the nature of the conflict due to your code being obfuscated.
You were able to debug and diagnose the issue further because you have both our script (which is not obfuscated and thus readable), and your own script in its unobfuscated form.
We did not blame you, nor attack you for your business decision to keep your scripts obfuscated. We stated this purely as the reason why we were not in a position to diagnose the issue further.
We gave you credit for writing that one line of code to call your script. And praised the effort you made. Hardly the tit for tat ego trip you claim.
We even offered to refer customers to you. But I would expect that our customers who read this would be pretty turned off by now. I know I am.

I don't suppose I can convince you otherwise, but your insistence on us having attacked your company is completely false, and again, the facts are laid out above for people to read for themselves.

Our contribution to this issue has been:

The (unobfuscated) source code to our script which has allowed you to look into the issue with ease.
Information on the nature and history of this problem.
Offers to co-operate with OpenCube so that we would be able to look further into the problem (which you rejected).
A suggested workaround (to switch the OpenCube script to the "100% pure CSS" mode you advertise).

Your attacks are unjustified here.

**David** · Nov-08-2007, 08:55 AM

Unfortunately this thread has somewhat gone off the deep end.

The last few posts don't add anything to the solution, and are basically just a baseless rant not supported by the facts.

I won't delete them, but leave it to the public to read the posts and come to their own conclusions.

The thread is now locked.

(We have 8000 posts in the forum and this is the first time ever I have had to lock a thread like this, sigh)

Announcement

Conflict with OpenCube Menu Software

Conflict with OpenCube Menu Software

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment