IE Still having problems with Mega Menu

[mankev]

In IE8 the .find function below works sporadically. Reloading the page many times in quick succession will cause the menus to work about 1 in 12 to 20 cycles. On our lab machine with IE8 a better success rate is obtained--about 1 in 10.

/* [Main] parse mega menu and establish all ARIA and Navigation classes */
$scope.find('ul.mb-menu > li').find('a:eq(0)').each(function (index, value) {

Using the code below above the Mega Menu loader will give expected alerts in Firefox but not IE8. IE will enter the code block sporadically as described above. ul.mb-menu is part of the static page so it is not an ajax loading issue. I have confirmed that the Ajax does load the include files for the menu. No errors are thrown. Looks like an alternative to .find will have to be found. I tried .filter() with some success, but it only entered the code block sporadicaly. Where is _exec : function (elm) being called, and what element is being passed to it? I have experienced similar problems in IE8 with the WYSYWIG editor (TinyMCE) in our CMS.

$scope.find('ul.mb-menu > li').each(function(){
alert("foo");
});

/* [Main] parse mega menu and establish all ARIA and Navigation classes */
$scope.find('ul.mb-menu > li').find('a:eq(0)').each(function (index, value) {
......

[pjackson28]

What you are experiencing seems like a race condition which can happen with asynchronous execution of JavaScript. Looking over the scripting and checking recent bugs that were found, a possible culprit was the execution one possible race is between the execution of the in page wet-boew-* calls (lines 800 to 811 of pe-ap.js) and the execution of the the global calls (lines 813 to 818 of pe-ap.js). Both blocks of code fire of asynchronous calls but the second block of code parses settings.js which was causing parsing errors in IE8 because of a hanging comma. What could have been happening is that the first block of code fired off the asynchronous menu bar call and then the second code block fired off the asynchronous call with the first call reaching the find() code in question at the same time as the second call reached the hanging comma. If that is the case then that would explain why it sometimes succeeds after a series of multiple refreshes as asynchronous calls are not always consistent with their execution speed (sometimes the second call could be winning the race).

This is all just a theory since I don't have pure IE8 to test with but if that is indeed the case then the recent fix to settings.js (earlier today) would resolve that issue. Could you please test with the latest code to see if removing the hanging comma from settings.js fixed the issue?

[mankev]

My first thoughts were of a race condition with the Ajax loading the menus, but some testing proved this to be false. I set Ajax to run synchronously, and removed that bit of code at line 93 and simply returned a string without luck. I also tried a .delay(1000).find()... without luck.

I came across that hanging comma last week, and removed it to no avail. This was before the bug that caused a failure in all the browsers. The comma error only surfaces when in compatibility mode, so I have my doubts about this being the cause. Since I updated my code with the latest I will remove it and test again. I will also try a few other things tomorrow. I think IE8 just breaks down if you throw to much code at it.

[mankev]

Removing the comma did not help. Its begining to look like the menu object is simply not loading or failing soon after.

[pjackson28]

What happens when you test on the GitHub working examples (e.g., http://wet-boew.github.com/wet-boew/demos/index-eng.html)? Do you get the same results there as you do locally? Do you only get the problem in IE8 or do you also get it in IE7? If you get it in IE7, are you testing with IE7 pure or IE8 in IE7 mode?

[mankev]

Not getting the expected results. Let me do some local testing, and I will get back.

[mankev]

Tom has downloaded the zip, and everithing works fine, but when he visits the pages on Git-hub its a no go.

[pjackson28]

That's because the changes haven't propagated yet from the master branch to the gh-pages branch. The gh-pages branch is what GitHub uses to publish the working examples. I won't be able to do the propagation until later tonight.

[pjackson28]

Fixed by #58 which was submitted and tested by @mankev.