After creating a webform using this module, I find that IE throws a "Stop running this script?" warning for all users.
According to Microsoft, this is likely caused by a excessive looping.
It does seem the the module's js uses looping fairly extensively. I've been working on a way to optimize the module, but thus far, I haven't been able to get rid of the message.
Is anyone else experiencing this problem? Any help would be appreciated.
Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | node1175.txt | 111.88 KB | grasmash |
Comments
Comment #1
tedbowIs there a reason you are using dev and not the rc1? I did run into this issue and changed the js file but that was a while ago.
Try the release candidate for this module and let me know if this still happens. Please report back either way so people know if this fixed it or not.
Comment #2
grasmash commentedI have just tried it with RC1 and I'm experiencing the same problem.
After a closer looks at the module, I see that the function 'Drupal.behaviors.webform_conditional.setVisibility()' makes a call to 'Drupal.behaviors.webform_conditional.TriggerDependents()' and that likewise, 'Drupal.behaviors.webform_conditional.TriggerDependents()' makes call to 'Drupal.behaviors.webform_conditional.setVisibility()'.
Could that be the source of the problem?
Comment #3
tedbowIf you created the form in a dev version it was probably possible to set up a form that would create an infinite loop. It shouldn't be possible anymore. But could be a problem if you are using the same form.
Is this problem only happening in IE? Other browsers are fine?
Is your form very large?
If you could use Node Export to export the form and paste it here.
Comment #4
grasmash commentedFirstly, thanks for your help. I appreciate your responsiveness-- this problem has been plaguing me!
-The problem is only occurring in IE. However, in other browsers, there is a significant lag between when the page loads and when the field visibility is set.
-The form was not created using the dev version.
-It is pretty big, but I've been cutting it down significantly in an attempt to improve efficiency.
My colleague and I have already made a number of changes to the module's logic to make it less expensive, but they don't seem to be getting at the root of the problem.
Comment #5
grasmash commentedHere's a dump of the node!
Comment #6
tedbowI imported your form and I get no problems in Firefox, Chrome, or IE 8 under Windows 7.
No script messages or errors. It doesn't seem to slow either. You form is large but I have run this module on forms that are bigger and multi-page.
If are running a modified version of the javascript file please try the current Javascript file for testing no make sure you still get the error.
I can't offer support in this forum unless you are using the regular javascript file b/c I don't what changes you have made.
If you think your js file would be an improvement to the current on you can make another issue with a patch for the js file. Before you submit a patch like that please test it on multi step forms as some the extra javascript is for the case where someone is going back and forth between separate pages of a form.
Comment #7
grasmash commentedNow that is strange...
I just reinstalled the webform conditional module with RC1 and imported the dump into a new node, but I'm experiencing the same issue. This happens on my local machine, my colleague's local machine, and on our server.
I may try this on a fresh Drupal install as well.
Comment #8
tedbowI did have this issue a long time ago. I made changes to the module use pseudo static javascript vars. Make sure temp internet files have been completely deleted so you are not still pulling in an old file.
Comment #9
grasmash commentedThe node worked fine on a fresh Drupal install. After some comparison, I discovered that the warning is not generated when using Drupal's default jQuery version of 1.2.4. However, using jQuery Update to upgrade jQuery to 1.3.2 immediately causes the warning to appear.
We've created a rudimentary field caching function that seems to optimize the script enough to prevent the error, but it's not entirely finished. Will have a patch for you soon.
Thanks!
Comment #10
tedbowmadmatter23,
I found the same issue with the jQuery update. Not sure why this would happened but I have a git branch to work on javascript improvements.
here: http://drupalcode.org/project/webform_conditional.git/shortlog/refs/head...
With the latest snapshot of this branch I no longer get the error on IE on your form. The Javascript should run much faster. Basically before I was attaching an onchange(or onclick) function for each field that was monitoring a field. That way if there were many components monitoring the same component there was a function call for each component.
Now on the server-side I group the components by monitor field when I create the Javascript settings. So now there is only 1 onchange(or onclick) function trigger field no matter how may components are monitoring it.
I also fixed a problem in the function "getComponentsByName" that was stopping this function from caching(via pseudo static var) results. The function was already working it just wasn't actually caching the components(though it was meant to be).
I have tested these changes locally and they seem to work with my forms and the one that you exported. Can you test it with your form b/c I have not looked at all it's settings to see how should really work?(need the whole snapshot b/c more than the js file has changed)
***Call for help*******
Also anyone else that could test this branch on a form that works with the current RC release would be appreciated!!!!
Please let me know if it works with your forms.
Comment #11
tedbowThese Javascript changes have been merged into the main dev branch.
Comment #12
tedbowI would appreciate help testing out and feedback about these JS changes. Especially testing on with long forms on IE.
Changing to "needs review" if I don't get an feedback I will close as fixed since I have tested it.
Comment #13
grasmash commentedSorry for the delay!
I actually did test the nightly snapshot and found that it was not working for me. Haven't tried the new dev version.
I will test this out ASAP, thanks!
Comment #14
grasmash commentedThe new updates to dev seem to have fixed the "Stop running script?" warning, but they have caused a few other IE specific issues.
Most importantly, I find that if I view a large webform node in IE8 and then attempt to open a new tab, IE crashes. This is a reproducible issue that seems to occur only when viewing webform nodes w/ webwform_conditional.
The updates also cause CSS to react differently to the webform. Maybe this is site specific, but I find that in IE, the webform's containing div doesn't seem to behave properly in the block-flow— it causes an overlap with html that appears after the webform. I haven't tried to troubleshoot this yet.
Comment #15
tedbowI merged the above js improvement branch above into the main branches. I think this has fixed the main issue in this thread
Comment #17
albert volkman commentedI'm experiencing this issue in the 7.x branch. Everything works, but IE8 users get the long running script error. It happens with jquery_update to 1.5, 1.7, and 1.8. I took a profile snapshot and it appears that the cause is the recursion from the Drupal.webform_conditional.setVisibility function. I'll post a patch as soon as I find a working solution.