Notes 7.0.3 Client throws Error in compile JavaScript on a form with not much JavaScript. Any ideas as to a potential cause?

Straight to the question and then the background.

What would cause a Notes 7.0.3 client to throw a JavaScript error "Error in compile JavaScript"?

Followup Question: what's a good tool for tracking JS errors in the Notes Client?

My suspcions: - flaky JS written by developer(s) - unusual input by user - memory management issues (Win XP, SP3) - corrupt Notes installation.

I've done my best to account for the first two and can't reproduce the error myself... full details below.

Google turns up nill for "Error in compile JavaScript" and I've gone through my usual channels for odd Notes errors to no avail.

Recap: A Notes 7.0.3 client throws the JavaScript error: Error in compile JavaScript when a form that has been compiled by Domino Designer 8.x has been opened and running on (you guessed it) some machines, not all. Two users complained that the error would be thrown after 10 -15 and 45-50 minutes of having the form in Edit mode whilst doing nothing else. "Just edit and let in go", they say. I got my hands on the same version of hardware and software they are running (waiting for one to stop by to show me what they actually launch during the day) and tried to reproduce the problem without success, even leaving the form in edit mode all day.

The JavaScript in question is pretty simple. Event onFocus() calls to a function that uses setInterval to track input field lengths to provide validation, but these fields do not need to be entered for the error to emerge. OnLoad has a call to a function that does a replace substring using a JS function that was custom built and is widely deployed without incident. All of this seems to be working fine for myself and our QA group which tested this thoroughly before deployment.

So my thought is that there may be some memory issues affecting their Notes Client, or something has caused their Notes Client installation to become flaky, maybe requiring an reinstall. Any ideas as to how this might be caused or how to prevent it would be greatly appreciated.

The answer seems to be "don't do this" when you have long edit times on a given field (the period matters here 100 ms gives us 5 min or so, 600 ms up to 18 or 20).

Use of setInterval over the short term with a reasonable period, say 500 ms, at least here in the Notes 7.0.3 client, is OK, especially where inputs are short and users are navigating over fields at a normal pace.

But, once you reach a condition where the document has been opened for a long period of time and the interval has not been cleared with clearInterval (such as from onBlur()), memory begins to leak in a predictable fashion.

The only operations taking place within our interval target function had to do with getting and setting values on the document object. If I comment everything out, there's no problem.