Moodle
  1. Moodle
  2. MDL-34328

Browser Unresponsive when editing turned on for large courses Moodle 2.3+

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.3, 2.3.2
    • Fix Version/s: 2.3.3
    • Component/s: Course
    • Testing Instructions:
      Hide

      Before starting, purge are caches aggressively in browser and moodle.

      Regression tests:

      Within a course (in which you have editing rights):

      • Turn Editing Mode on
      • Drag a resource to another section
      • Drag a section to a new position
      • Drag a file in from the desktop
      • Drag the newly created resource to a new position
      • Edit the newly created resource's title (pencil icon)
      • Hide a resource or activity
      • Unhide a resource or activity
      • Toggle a resource or activity's group mode
      • Drag blocks around
      • Use the +/- icons to toggle visibility of blocks, and ensure that no drag event is initialised upon completion of the show/hide
      • Toggle visibility of a section using the eye icon
      • Toggle highlighting on a section using the lightbulb icon

      Performance improvements:

      These are quite difficult to test. The best thing I can advise is:

      • Use a restored copy of http://qa.moodle.net/course/view.php?id=2
      • Use IE
      • Open the Profiler on IE
        • Start profiling
        • Refresh the page
        • When the JS seems to have finished uipdating the page, stop profiling
        • Take a look in Tree view - dig down if you fancy
      • Compare with and without the patch
      Show
      Before starting, purge are caches aggressively in browser and moodle. Regression tests: Within a course (in which you have editing rights): Turn Editing Mode on Drag a resource to another section Drag a section to a new position Drag a file in from the desktop Drag the newly created resource to a new position Edit the newly created resource's title (pencil icon) Hide a resource or activity Unhide a resource or activity Toggle a resource or activity's group mode Drag blocks around Use the +/- icons to toggle visibility of blocks, and ensure that no drag event is initialised upon completion of the show/hide Toggle visibility of a section using the eye icon Toggle highlighting on a section using the lightbulb icon Performance improvements: These are quite difficult to test. The best thing I can advise is: Use a restored copy of http://qa.moodle.net/course/view.php?id=2 Use IE Open the Profiler on IE Start profiling Refresh the page When the JS seems to have finished uipdating the page, stop profiling Take a look in Tree view - dig down if you fancy Compare with and without the patch
    • Affected Branches:
      MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-34328-master-4
    • Rank:
      42696

      Description

      To reproduce the problem I follow the steps below:

      1. Browser Internet Explorer 8 - version of Moodle 2.3 or 2.3.1 (Moodle 2.3+ (Build: 20120701))
      2. Standard theme applied and base moodle installed (no 3rd party modules or plugins etc)
      3. Restored Feature demo course from demo.moodle.net
      4. Visit the course as teacher or high role with editing permissions
      5. Click the "Turn on editing" button - the page is slow to load but works
      6. Repeat the restore of the same back up on the initial course (merge into course)
      7. Visit the course as teacher or high role with editing permissions
      8. Click the "Turn on editing" button

      Browser becomes unresponsive then throws message

      'A script on this page is causing Internet Explorer to run slowly etc'

      I have tried turning off AJAX for the site and to source the YUI externally but without any improvement. Only when I remove a number of activities/topic sections does it become responsive again. The same problem can be reproduced when I use other sample courses that have 20+ topic sections.

      I was able to produce on 2.3 so decide to apply latest 2.3.1 build but did not help. The same issue appears on IE9 but without message thrown by the browser. On IE9 it is unresponsive for about 30secs or so then decides to work again.

      1. Course Parris Business Technology Applications_php.htm
        472 kB
        Jeff Green
      2. IE9 Profile after page load.csv
        1 kB
        Michael de Raadt
      3. IE9 Profile during page load.csv
        0.2 kB
        Michael de Raadt
      4. master.csv
        231 kB
        Andrew Nicols
      5. master plus 34328.csv
        231 kB
        Andrew Nicols
      1. screenshot-1.jpg
        48 kB
      2. Screen Shot 2012-10-17 at 09.26.06.png
        204 kB
      3. Screen Shot 2012-10-17 at 09.28.14.png
        259 kB
      4. Screen Shot 2012-10-17 at 09.30.49.png
        213 kB

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          I was able to reproduce this issue. I backed-up and restored the Features Demo course merging three copies into one course.

          The problem seems to be across browsers, but is more noticeable in IE. I noticed the same results in FF and Chrome.

          The page load times are not affected. It is a script that runs after the page is loaded. With a large number of activities/sections the browser continuously consumes a large amount of CPU while seeing to do nothing. The activity chooser is loaded and the drag-and-drop controls are loaded, but the browser continues to run some script in the background.

          I tried to trace the problem in JS. It may be related to drag-and-drop of activities/resource as this seems to take a long time to load in a trace, particularly on IE. But then, the problem continues after this is loaded, so perhaps that is not the case. It's hard to trace something that doesn't stop.

          Show
          Michael de Raadt added a comment - I was able to reproduce this issue. I backed-up and restored the Features Demo course merging three copies into one course. The problem seems to be across browsers, but is more noticeable in IE. I noticed the same results in FF and Chrome. The page load times are not affected. It is a script that runs after the page is loaded. With a large number of activities/sections the browser continuously consumes a large amount of CPU while seeing to do nothing. The activity chooser is loaded and the drag-and-drop controls are loaded, but the browser continues to run some script in the background. I tried to trace the problem in JS. It may be related to drag-and-drop of activities/resource as this seems to take a long time to load in a trace, particularly on IE. But then, the problem continues after this is loaded, so perhaps that is not the case. It's hard to trace something that doesn't stop.
          Hide
          Dan Poltawski added a comment -
          Show
          Dan Poltawski added a comment - This sounds similar issue: http://moodle.org/mod/forum/discuss.php?d=207142
          Hide
          Virgil Ashruf added a comment -

          I can reproduce this problem as well. I have upgraded a large environment from 2.2.3+ to 2.3.1. Teachers who are using the summer holiday to update their courses are experiencing a lot of trouble completing their work. In IE9 the browser completely freezes. In IE8 the browser complete shuts down. Chrome kills the page and Firefox becomes less responsive.

          For a moment turning off the YUI-caching seemed to fix things. This leads me to believe it has to do with the drag-drop functionality. (AJAX, is it?)

          Show
          Virgil Ashruf added a comment - I can reproduce this problem as well. I have upgraded a large environment from 2.2.3+ to 2.3.1. Teachers who are using the summer holiday to update their courses are experiencing a lot of trouble completing their work. In IE9 the browser completely freezes. In IE8 the browser complete shuts down. Chrome kills the page and Firefox becomes less responsive. For a moment turning off the YUI-caching seemed to fix things. This leads me to believe it has to do with the drag-drop functionality. (AJAX, is it?)
          Hide
          Chien Wen-Chang(簡文章) added a comment -

          I tried to disable Site administration ► Appearance ► Moodle Docs ► Open in new window. In IE9 the browser completely does not freezes.

          Show
          Chien Wen-Chang(簡文章) added a comment - I tried to disable Site administration ► Appearance ► Moodle Docs ► Open in new window. In IE9 the browser completely does not freezes.
          Hide
          richard havinga added a comment - - edited

          Once I turn off Ajax and Purge all caches, this issue goes away in Internet Explorer which does suggest it might be to do with drag and drop added in 2.3. Is there anyway to disable just drag and drop to test this? As mentioned previously it appears across browser but causes major issues in IE.

          Show
          richard havinga added a comment - - edited Once I turn off Ajax and Purge all caches, this issue goes away in Internet Explorer which does suggest it might be to do with drag and drop added in 2.3. Is there anyway to disable just drag and drop to test this? As mentioned previously it appears across browser but causes major issues in IE.
          Hide
          Marty added a comment -

          Some of our users are also suffering from this bug. I've managed to replicate this error myself in IE8 and it does appear to be triggered by courses with a large number of resources. Switching the course format to one topic per page allows users to avoid triggering the bug in most cases because there are less resources being rendered per page.

          I'm happy to do more testing/debugging, but I'm not sure how I do this with JS.

          Show
          Marty added a comment - Some of our users are also suffering from this bug. I've managed to replicate this error myself in IE8 and it does appear to be triggered by courses with a large number of resources. Switching the course format to one topic per page allows users to avoid triggering the bug in most cases because there are less resources being rendered per page. I'm happy to do more testing/debugging, but I'm not sure how I do this with JS.
          Hide
          Michael Woods added a comment -

          Yes, we are experiencing this also, and it's driving our staff crazy. It is mainly IE.

          What I've found is that it's almost purely a factor of the number of SECTIONS in a course, not really the number of resources/activities. Eg. Load time for a course with 20 BLANK sections is almost not usable in edit mode, but a course with 1 section containing 100 resources is fine. We have had to urgently shift some quite reluctant staff away from IE to Firefox and Chrome to get them using Moodle again.

          I tried to debug the problematic code without much luck at all.

          Show
          Michael Woods added a comment - Yes, we are experiencing this also, and it's driving our staff crazy. It is mainly IE. What I've found is that it's almost purely a factor of the number of SECTIONS in a course, not really the number of resources/activities. Eg. Load time for a course with 20 BLANK sections is almost not usable in edit mode, but a course with 1 section containing 100 resources is fine. We have had to urgently shift some quite reluctant staff away from IE to Firefox and Chrome to get them using Moodle again. I tried to debug the problematic code without much luck at all.
          Hide
          Dan Poltawski added a comment -

          Raising the priority, since it seems to be affecting anyone with a large course.

          Show
          Dan Poltawski added a comment - Raising the priority, since it seems to be affecting anyone with a large course.
          Hide
          Garret Gengler added a comment -

          I read about this issue on the forums, and it reminded me of problems I experienced with MSIE some years ago.

          This may seem out of left field, and may not work... but if you are running Apache server, it's worth trying:

          Open up /etc/apache2/apache2.conf, and check the value of KeepAliveTimeout.

          If it is set to 15 (the default), I believe you need to raise it. We use a value of 90 for all of our servers.

          Here's why:

          MSIE is compiled with a minimum keep-alive timeout of 60 seconds. You can override this in the Windows Registry, but it's not practical to do so for every computer that connects to your website.

          Other browsers (Firefox/Chrome/Safari) have much shorter values. So they are generally not affected by this issue.

          Keep-alives are persistent HTTP connections that a web browser can hold open with your server. By sharing the HTTP and SSL overhead across multiple GET/POST requests, they increase the speed of downloading a page and all its required assets.

          MSIE will assume any keep-alive is still valid, until it is at least 60 seconds old. So if Apache is closing keep-alives before 60 seconds, you can get in a situation where MSIE tries to push GET and POST operations into a connection handle that is no longer valid.

          When we saw this first, when we were running Moodle 1.5, it was obvious, because the browser would display an error 500. But I suspect that with background AJAX scripts in Moodle 2.x, it could be failing to connect in the background.

          There is generally nothing in the server logs to help trouble shoot this. The server is all too happy to kill off the stale keep-alive, and then the client can no longer talk on that pipe. So it actually reduces server load.

          I added a warning note about this Apache setting to the Moodle 1.9 performance docs, but it appears to have been lost when the docs for 2.x were written.

          If someone can confirm that this solution helps them with Moodle 2, I'll make sure to add it back to the docs.

          Show
          Garret Gengler added a comment - I read about this issue on the forums, and it reminded me of problems I experienced with MSIE some years ago. This may seem out of left field, and may not work... but if you are running Apache server, it's worth trying: Open up /etc/apache2/apache2.conf, and check the value of KeepAliveTimeout. If it is set to 15 (the default), I believe you need to raise it. We use a value of 90 for all of our servers. Here's why: MSIE is compiled with a minimum keep-alive timeout of 60 seconds. You can override this in the Windows Registry, but it's not practical to do so for every computer that connects to your website. Other browsers (Firefox/Chrome/Safari) have much shorter values. So they are generally not affected by this issue. Keep-alives are persistent HTTP connections that a web browser can hold open with your server. By sharing the HTTP and SSL overhead across multiple GET/POST requests, they increase the speed of downloading a page and all its required assets. MSIE will assume any keep-alive is still valid, until it is at least 60 seconds old. So if Apache is closing keep-alives before 60 seconds, you can get in a situation where MSIE tries to push GET and POST operations into a connection handle that is no longer valid. When we saw this first, when we were running Moodle 1.5, it was obvious, because the browser would display an error 500. But I suspect that with background AJAX scripts in Moodle 2.x, it could be failing to connect in the background. There is generally nothing in the server logs to help trouble shoot this. The server is all too happy to kill off the stale keep-alive, and then the client can no longer talk on that pipe. So it actually reduces server load. I added a warning note about this Apache setting to the Moodle 1.9 performance docs, but it appears to have been lost when the docs for 2.x were written. If someone can confirm that this solution helps them with Moodle 2, I'll make sure to add it back to the docs.
          Hide
          Marty added a comment -

          Thanks for the suggested fix Garret, I'll modify our Apache settings and report back ASAP!

          Marty

          Show
          Marty added a comment - Thanks for the suggested fix Garret, I'll modify our Apache settings and report back ASAP! Marty
          Hide
          Marty added a comment - - edited

          Unfortunately, changing the KeepAliveTimeout doesn't appear to help. The slow script pop-up message still appears and the page takes approx 50 seconds to load (after clicking the dialogue box twice to avoid killing the script). To put this into context, when using Firefox the same course page loads into edit mode in 8 seconds or less.

          Marty

          Show
          Marty added a comment - - edited Unfortunately, changing the KeepAliveTimeout doesn't appear to help. The slow script pop-up message still appears and the page takes approx 50 seconds to load (after clicking the dialogue box twice to avoid killing the script). To put this into context, when using Firefox the same course page loads into edit mode in 8 seconds or less. Marty
          Hide
          Mark O'Neal added a comment -

          Just wanted to note that we were having issues with a large topic section (83 topics, ~5 resources per topic), and insanely slow load times on multiple browsers (Firefox, Chrome, Safari). The change above for Moodle Docs (turning off opening it in a new window) substantially improved our load times. (15 seconds to load the page in editing mode vs. 45 seconds previously, verified.) I'm a bit perplexed as to where the connection to the code is that would cause that, however.

          Show
          Mark O'Neal added a comment - Just wanted to note that we were having issues with a large topic section (83 topics, ~5 resources per topic), and insanely slow load times on multiple browsers (Firefox, Chrome, Safari). The change above for Moodle Docs (turning off opening it in a new window) substantially improved our load times. (15 seconds to load the page in editing mode vs. 45 seconds previously, verified.) I'm a bit perplexed as to where the connection to the code is that would cause that, however.
          Hide
          richard havinga added a comment -

          I wonder whether this is specifically a YUI issue:

          http://yuilibrary.com/projects/yui3/ticket/2530391

          Show
          richard havinga added a comment - I wonder whether this is specifically a YUI issue: http://yuilibrary.com/projects/yui3/ticket/2530391
          Hide
          richard havinga added a comment -

          A similiar user experience issue to this for user enrolments can be seen here:

          http://tracker.moodle.org/browse/MDL-33448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs

          It looks like there must have been a number of changes that have been implemented in 2.3 that cause this issue.

          Show
          richard havinga added a comment - A similiar user experience issue to this for user enrolments can be seen here: http://tracker.moodle.org/browse/MDL-33448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs It looks like there must have been a number of changes that have been implemented in 2.3 that cause this issue.
          Hide
          Michael Woods added a comment -

          Thanks for the suggestion re: Moodle Docs (turning off opening in new window). A massive improvement in load times! I tried on a 20 section course that often just failed to load at all in IE9 previously, and after the setting change it fully loaded in edit mode in 28 seconds - a vast improvement. It obviously could be improved more, but at least IE is usable again by staff who still prefer that browser.

          Show
          Michael Woods added a comment - Thanks for the suggestion re: Moodle Docs (turning off opening in new window). A massive improvement in load times! I tried on a 20 section course that often just failed to load at all in IE9 previously, and after the setting change it fully loaded in edit mode in 28 seconds - a vast improvement. It obviously could be improved more, but at least IE is usable again by staff who still prefer that browser.
          Hide
          Anthony Borrow added a comment -

          I had a production site that was having various errors. I looked under site administration and had it show only fatal errors and unchecked strict xml and that seemed to resolve a similar issue where folks could not even see the home page to login. That seemed to allow the site to work again with IE. Hope this helps. Peace - Anthony

          Show
          Anthony Borrow added a comment - I had a production site that was having various errors. I looked under site administration and had it show only fatal errors and unchecked strict xml and that seemed to resolve a similar issue where folks could not even see the home page to login. That seemed to allow the site to work again with IE. Hope this helps. Peace - Anthony
          Hide
          Martin Dougiamas added a comment -

          Does switching off strict XML help anyone else?

          Show
          Martin Dougiamas added a comment - Does switching off strict XML help anyone else?
          Hide
          Martin Dougiamas added a comment -

          Assigning back to moodle.com as it's in core now. Ruslan, you're free to help of course if you want to!

          Show
          Martin Dougiamas added a comment - Assigning back to moodle.com as it's in core now. Ruslan, you're free to help of course if you want to!
          Hide
          Marty added a comment - - edited

          Hi Martin,

          No, it doesn't seem to help us. We've always had this setting switched off by default on our production server.

          The loading times of large pages is becoming a bigger problem for us as more of our editing teachers try out Moodle 2 for the first time. The only workaround that seems to help is switching to the one topic per page feature, but this is confusing some students because the course home page looks empty.

          If you need me to do any more digging into this issue I'm more than happy to do so.

          Marty

          Show
          Marty added a comment - - edited Hi Martin, No, it doesn't seem to help us. We've always had this setting switched off by default on our production server. The loading times of large pages is becoming a bigger problem for us as more of our editing teachers try out Moodle 2 for the first time. The only workaround that seems to help is switching to the one topic per page feature, but this is confusing some students because the course home page looks empty. If you need me to do any more digging into this issue I'm more than happy to do so. Marty
          Hide
          richard havinga added a comment -

          It also doesn't help us at all unfortunately as I also always had this turned off as well.

          Show
          richard havinga added a comment - It also doesn't help us at all unfortunately as I also always had this turned off as well.
          Hide
          John Russo added a comment -

          I've adjusted the SSL keepalive to be dependent on the browser version in Apache by using directions here http://blog.vpire.com/822/apache-ssl-slow-on-internet-explorer/ Adding this statement definitely reduced the loading time, but the stop script dialogue box still appears.

          Show
          John Russo added a comment - I've adjusted the SSL keepalive to be dependent on the browser version in Apache by using directions here http://blog.vpire.com/822/apache-ssl-slow-on-internet-explorer/ Adding this statement definitely reduced the loading time, but the stop script dialogue box still appears.
          Hide
          Mark Ward added a comment -

          I've been digging around in an attempt to understand this today. IE8 is a bit useless so I used Google Chrome's timeline feature to check what the page was doing AFTER it has loaded (which is when the lag kicks in for me).

          I checked this on Moodle 2.2 and then Moodle 2.3. I found that m2.2 had 239 JavaScript events over 10 seconds, each of which was linked to yui_combo.php:8 . M2.3 on the other hand was not producing any lag and was doing much less with just 10 of these events over 10 seconds and again all linked to yui_combo.php:8. I reloaded a few times in a row and got the same result.

          The page was responding fine and I wondered if I had triggered something to fix the problem. I reloaded in IE8 and the issue raised it's head again so I quickly jumped back to Chrome to repeat the experiment. The timeline survived just 13ms before it crashed having been hit with 543 JavaScript events. All of the hits were for yui_combo.php:5493 this time.

          After this I waited a while and tried purging the cache to ensure this wasn't somehow being caused by accessing the site with an IE user agent. But the timeline went mental again recording over 5000 JavaScript events in 4 seconds made up of yui_combo.php:5493 and yui_combo.php:363 events.

          I still can't understand why, on Chrome at least, I'm seeing some page loads work fine and other going crazy when I'm visiting the same course. Hopefully someone knows what the 5493 and 363 numbers refer to?

          Show
          Mark Ward added a comment - I've been digging around in an attempt to understand this today. IE8 is a bit useless so I used Google Chrome's timeline feature to check what the page was doing AFTER it has loaded (which is when the lag kicks in for me). I checked this on Moodle 2.2 and then Moodle 2.3. I found that m2.2 had 239 JavaScript events over 10 seconds, each of which was linked to yui_combo.php:8 . M2.3 on the other hand was not producing any lag and was doing much less with just 10 of these events over 10 seconds and again all linked to yui_combo.php:8. I reloaded a few times in a row and got the same result. The page was responding fine and I wondered if I had triggered something to fix the problem. I reloaded in IE8 and the issue raised it's head again so I quickly jumped back to Chrome to repeat the experiment. The timeline survived just 13ms before it crashed having been hit with 543 JavaScript events. All of the hits were for yui_combo.php:5493 this time. After this I waited a while and tried purging the cache to ensure this wasn't somehow being caused by accessing the site with an IE user agent. But the timeline went mental again recording over 5000 JavaScript events in 4 seconds made up of yui_combo.php:5493 and yui_combo.php:363 events. I still can't understand why, on Chrome at least, I'm seeing some page loads work fine and other going crazy when I'm visiting the same course. Hopefully someone knows what the 5493 and 363 numbers refer to?
          Hide
          Dan Poltawski added a comment -

          Hi,

          To try and debug this you could try to switch off yui combo loading and cachejs, to get the actual lines running in Admin > Appearance > AJAX & JS

          Show
          Dan Poltawski added a comment - Hi, To try and debug this you could try to switch off yui combo loading and cachejs, to get the actual lines running in Admin > Appearance > AJAX & JS
          Hide
          Mark Ward added a comment - - edited

          OK, after doing that this is what I get: http://i.imgur.com/69NV0.jpg

          The scripts firing off the events just seem to be core YUI functions, but I haven't had any luck figuring out what actually ordered the events yet.

          edit: after playing around a bit more and stepping through the execution I tracked the yui.js events back to dd-drop.js:456, _createShim()?

          edit2: the event-base.js stuff is looping round and round referencing y.one('#click502bc0bc230a110') on the page I am looking at here. When I look through the page source this relates to a moodledocs page. Given I have tried deleting out the dragdrop stuff and I still have the same problem I am now running on the hypothesis that it's these events that are causing IE to conk out.

          Show
          Mark Ward added a comment - - edited OK, after doing that this is what I get: http://i.imgur.com/69NV0.jpg The scripts firing off the events just seem to be core YUI functions, but I haven't had any luck figuring out what actually ordered the events yet. edit: after playing around a bit more and stepping through the execution I tracked the yui.js events back to dd-drop.js:456, _createShim()? edit2: the event-base.js stuff is looping round and round referencing y.one('#click502bc0bc230a110') on the page I am looking at here. When I look through the page source this relates to a moodledocs page. Given I have tried deleting out the dragdrop stuff and I still have the same problem I am now running on the hypothesis that it's these events that are causing IE to conk out.
          Show
          Paul Nijbakker added a comment - I don't know if it is any help, but the error I got (this was in Firefox, I.E. is practically unusable presently) was that a script is running that is making the page unresponsive and this was the script: Script: http://moodle.tokem.fi/theme/yui_combo.php?3.5.1/build/oop/oop.js&3.5.1/build/event-custom-base/event-custom-base.js&3.5.1/build/dom-core/dom-core.js&3.5.1/build/dom-base/dom-base.js&3.5.1/build/selector-native/selector-native.js&3.5.1/build/selector/selector.js&3.5.1/build/node-core/node-core.js&3.5.1/build/node-base/node-base.js&3.5.1/build/event-base/event-base.js&3.5.1/build/event-delegate/event-delegate.js&3.5.1/build/node-event-delegate/node-event-delegate.js&3.5.1/build/pluginhost-base/pluginhost-base.js&3.5.1/build/pluginhost-config/pluginhost-config.js&3.5.1/build/node-pluginhost/node-pluginhost.js&3.5.1/build/dom-style/dom-style.js&3.5.1/build/dom-screen/dom-screen.js&3.5.1/build/node-screen/node-screen.js&3.5.1/build/node-style/node-style.js:3820
          Hide
          Dan Poltawski added a comment -

          Thanks for your investigations guys. Its worying that its a yui core thing, but maybe its something simple we have got very wrong.

          Show
          Dan Poltawski added a comment - Thanks for your investigations guys. Its worying that its a yui core thing, but maybe its something simple we have got very wrong.
          Hide
          Jeremiah Jackson added a comment -

          On our production servers that have been upgraded to 2.3 we are experiencing this on larger courses. The one I am looking at right now has 12 sections. Some of my users who have IE are getting long running script errors.

          Show
          Jeremiah Jackson added a comment - On our production servers that have been upgraded to 2.3 we are experiencing this on larger courses. The one I am looking at right now has 12 sections. Some of my users who have IE are getting long running script errors.
          Hide
          Mark Ward added a comment - - edited

          Watching the code execute it looks a lot like it's getting stuck in a loop trying to find an element on the page and jumping between _poll() in event-base.js and query(selector) in selector-native.js. Here's an interesting experiment to highlight what is going on:

          1) Follow Dan's instructions to disable YUI combo loading and cachejs
          2) Open up lib/yui.3.5.1/build/selector-native/selector-native.js
          3) Go to around line 132 within the query() function and add "console.log(selector);" to the top
          4) Use Chrome to load the page and watch the output to console... (alternatively use alert() and hold down return);

          By doing this we can see what is being passed to the selector. For me, aside from the usual stuff you would expect to see, I'm getting an loop of "#click502ca54b4f8583", "#click502ca54b4f8584", "#click502ca54b4f8585" going on indefinitely. http://i.imgur.com/Rtd3U.jpg

          These selectors are being fired by the page (view.php itself), but the console output shows far more occurrences (Chrome gave up at 100,000) than the amount on the page (221). It's also worth noting that at least some of the elements that are being referenced aren't actually on the page (on my course at least).

          Edit: Setting doctonewwindow to "no" stopped this behaviour.

          Show
          Mark Ward added a comment - - edited Watching the code execute it looks a lot like it's getting stuck in a loop trying to find an element on the page and jumping between _poll() in event-base.js and query(selector) in selector-native.js. Here's an interesting experiment to highlight what is going on: 1) Follow Dan's instructions to disable YUI combo loading and cachejs 2) Open up lib/yui.3.5.1/build/selector-native/selector-native.js 3) Go to around line 132 within the query() function and add "console.log(selector);" to the top 4) Use Chrome to load the page and watch the output to console... (alternatively use alert() and hold down return); By doing this we can see what is being passed to the selector. For me, aside from the usual stuff you would expect to see, I'm getting an loop of "#click502ca54b4f8583", "#click502ca54b4f8584", "#click502ca54b4f8585" going on indefinitely. http://i.imgur.com/Rtd3U.jpg These selectors are being fired by the page (view.php itself), but the console output shows far more occurrences (Chrome gave up at 100,000) than the amount on the page (221). It's also worth noting that at least some of the elements that are being referenced aren't actually on the page (on my course at least). Edit: Setting doctonewwindow to "no" stopped this behaviour.
          Hide
          Andrew Nicols added a comment -

          Hmm,

          If doctonewwindow is preventing the issues, could you try editing lib/outputrenderers.php, find function doc_link() and comment out the add_action_handler line.

          I suspect that the way in which the add_action_handler works is broken somehow. It shouldn't loop endlessly though...

          Andrew

          Show
          Andrew Nicols added a comment - Hmm, If doctonewwindow is preventing the issues, could you try editing lib/outputrenderers.php, find function doc_link() and comment out the add_action_handler line. I suspect that the way in which the add_action_handler works is broken somehow. It shouldn't loop endlessly though... Andrew
          Hide
          Mark Ward added a comment -

          Hi Andrew! Well even with Javascript not going mental and Drag and Drop disabled I am finding load times on Internet Explorer 8 take twice as long under the same conditions on Moodle 2.2 and even then the page is laggy. So it looks like there needs to be a separate issue about IE specifically.

          Unfortunately we are now going to postpone upgrading to 2.3 since most of our PCs are running XP with IE8.

          Show
          Mark Ward added a comment - Hi Andrew! Well even with Javascript not going mental and Drag and Drop disabled I am finding load times on Internet Explorer 8 take twice as long under the same conditions on Moodle 2.2 and even then the page is laggy. So it looks like there needs to be a separate issue about IE specifically. Unfortunately we are now going to postpone upgrading to 2.3 since most of our PCs are running XP with IE8.
          Hide
          Paul Nicholls added a comment -

          I've only just become aware of this issue (we're still running 1.9, working towards upgrading to 2.3!) and am currently looking into it. I've already made one major improvement and one smaller improvement, both related to the initialisation of resource drag and drop - and I should be able to do something similar for section drag and drop. As seems to have been mentioned here in the comments already, it's still sluggish after it's all done, though - but that may be a little better than it was as well. I'll assign this to myself (since it doesn't seem to be assigned to any individual developer, I assume nobody else is working on it yet?) and add pull details when I'm done.

          Show
          Paul Nicholls added a comment - I've only just become aware of this issue (we're still running 1.9, working towards upgrading to 2.3!) and am currently looking into it. I've already made one major improvement and one smaller improvement, both related to the initialisation of resource drag and drop - and I should be able to do something similar for section drag and drop. As seems to have been mentioned here in the comments already, it's still sluggish after it's all done, though - but that may be a little better than it was as well. I'll assign this to myself (since it doesn't seem to be assigned to any individual developer, I assume nobody else is working on it yet?) and add pull details when I'm done.
          Hide
          Michael de Raadt added a comment -

          Thanks for working on this, Paul.

          Show
          Michael de Raadt added a comment - Thanks for working on this, Paul.
          Hide
          Jeremiah Jackson added a comment -

          I'm not a developer but I am a pretty decent sysadmin and can understand a fair bit of php. Is there any debug logs that I could parse out that would help you all in any way? Should I just start looking through my logs and see if I see anything "weird". Just want to help in anyway I can.

          Show
          Jeremiah Jackson added a comment - I'm not a developer but I am a pretty decent sysadmin and can understand a fair bit of php. Is there any debug logs that I could parse out that would help you all in any way? Should I just start looking through my logs and see if I see anything "weird". Just want to help in anyway I can.
          Hide
          Paul Nicholls added a comment -

          Jeremiah, thanks for the offer, but this is all down to Javascript - so there aren't really any logs which are of any help here. I've made some improvements, but I'm hoping to make more yet before I attach code here - it's really just down to finding the time; an urgent project distracted me from this (which isn't quite so urgent for us since we're still on 1.9) yesterday, but now I'm hopefully able to focus on it again.

          Show
          Paul Nicholls added a comment - Jeremiah, thanks for the offer, but this is all down to Javascript - so there aren't really any logs which are of any help here. I've made some improvements, but I'm hoping to make more yet before I attach code here - it's really just down to finding the time; an urgent project distracted me from this (which isn't quite so urgent for us since we're still on 1.9) yesterday, but now I'm hopefully able to focus on it again.
          Hide
          Mark Ward added a comment -

          Hi Paul,

          What confuses me the most about this is that on Internet Explorer 8 I was pausing the JS engine and then scrolling up and down the page. The response speed was very slow and laggy even though the JS engine (apparently) wasn't doing anything.

          The obvious target seems to be DragDrop, again though even when I killed that off it was laggy. Very odd :S

          Show
          Mark Ward added a comment - Hi Paul, What confuses me the most about this is that on Internet Explorer 8 I was pausing the JS engine and then scrolling up and down the page. The response speed was very slow and laggy even though the JS engine (apparently) wasn't doing anything. The obvious target seems to be DragDrop, again though even when I killed that off it was laggy. Very odd :S
          Hide
          Chris Meyer added a comment -

          The MO for javascript problems that are worse under IE is using for ( in ) loops to traverse arrays. for (in) in Javascript is only for traversing objects and will fail on arrays, particularly with IE.

          My guess is you guys already know this, but just in case... I struggled with this a long time since PHP does use for (in) with arrays.

          Hope you get it fixed soon. We really need it bad at CESA 10 in Chippewa Falls Wisconsin.

          Love your product.

          Show
          Chris Meyer added a comment - The MO for javascript problems that are worse under IE is using for ( in ) loops to traverse arrays. for (in) in Javascript is only for traversing objects and will fail on arrays, particularly with IE. My guess is you guys already know this, but just in case... I struggled with this a long time since PHP does use for (in) with arrays. Hope you get it fixed soon. We really need it bad at CESA 10 in Chippewa Falls Wisconsin. Love your product.
          Hide
          Chris Meyer added a comment -

          Case in point for for(in) in javascript.

          Taken from blocks/tags/coursetags.js:

          function ctags_show_div(mydiv) {
          for(x in coursetagdivs) {
          if(mydiv == coursetagdivs[x])

          { document.getElementById(coursetagdivs[x]).style.display="block"; }

          else

          { document.getElementById(coursetagdivs[x]).style.display="none"; }

          }
          return false;
          }

          This function uses for(in) to traverse an associative array named coursetagdivs. Now this looks like it works because an array is also an object. The problem is, the for(in) will return ALL attributes of the associative array object, not just it's array elements. Sometimes this can cause unexpected results. I have come to avoid this usage because it makes my code unstable - especially under IE.

          Hope this is useful : )

          Show
          Chris Meyer added a comment - Case in point for for(in) in javascript. Taken from blocks/tags/coursetags.js: function ctags_show_div(mydiv) { for(x in coursetagdivs) { if(mydiv == coursetagdivs [x] ) { document.getElementById(coursetagdivs[x]).style.display="block"; } else { document.getElementById(coursetagdivs[x]).style.display="none"; } } return false; } This function uses for(in) to traverse an associative array named coursetagdivs. Now this looks like it works because an array is also an object. The problem is, the for(in) will return ALL attributes of the associative array object, not just it's array elements. Sometimes this can cause unexpected results. I have come to avoid this usage because it makes my code unstable - especially under IE. Hope this is useful : )
          Hide
          Chris Meyer added a comment -

          Other examples of for(in) used to traverse associative arrays in Moodle can be found in:

          course/yui/coursebase/coursebase.js
          course/yui/toolboxes/toolboxes.js
          course/yui/dragdrop/toolboxes.js

          I'll stop commenting about this with this post, because if I'm off the mark, I'm wasting people's time. : )

          Show
          Chris Meyer added a comment - Other examples of for(in) used to traverse associative arrays in Moodle can be found in: course/yui/coursebase/coursebase.js course/yui/toolboxes/toolboxes.js course/yui/dragdrop/toolboxes.js I'll stop commenting about this with this post, because if I'm off the mark, I'm wasting people's time. : )
          Hide
          Paul Nicholls added a comment -

          I've attached a set of patches which make performance improvements to the course dragdrop, resource toolboxes and URL selects (add resource/activity dropdowns). In a real-world course which previously initialised so slowly in IE8 that it triggered a slow script warning, it now initialises in about 10-15 seconds; while it's still much slower than ideal, it's a considerable improvement - so this isn't necessarily the end of it, but I think it's a sufficiently good start that it's worth proceeding with. I'll submit it for peer review.

          If there are any standard regression tests surrounding the changed areas (course dragdrop, resource toolboxes, add resource/activity dropdowns), they should probably be performed in addition to / in conjunction with the testing instructions listed above.

          Show
          Paul Nicholls added a comment - I've attached a set of patches which make performance improvements to the course dragdrop, resource toolboxes and URL selects (add resource/activity dropdowns). In a real-world course which previously initialised so slowly in IE8 that it triggered a slow script warning, it now initialises in about 10-15 seconds; while it's still much slower than ideal, it's a considerable improvement - so this isn't necessarily the end of it, but I think it's a sufficiently good start that it's worth proceeding with. I'll submit it for peer review. If there are any standard regression tests surrounding the changed areas (course dragdrop, resource toolboxes, add resource/activity dropdowns), they should probably be performed in addition to / in conjunction with the testing instructions listed above.
          Hide
          Tom Butkiewicz added a comment -

          After testing the above changes, I cannot seem to get drag/drop functionality working.

          Course load times are definitely improved, but even with 'enableajax' enabled all I get is the click to move functionality site-wide.

          Also, it seems like the activity chooser link 'Add an activity or resource' stops working after the changes.

          Hope this helps.

          Show
          Tom Butkiewicz added a comment - After testing the above changes, I cannot seem to get drag/drop functionality working. Course load times are definitely improved, but even with 'enableajax' enabled all I get is the click to move functionality site-wide. Also, it seems like the activity chooser link 'Add an activity or resource' stops working after the changes. Hope this helps.
          Hide
          Paul Nicholls added a comment - - edited

          Hi Tom,
          Can you please clarify which version of Moodle you're using and how you applied the changes above?

          Cheers,
          Paul

          Edit: Also, please try purging Moodle's caches - your Moodle site may have (some of) the old JavaScript cached.

          Show
          Paul Nicholls added a comment - - edited Hi Tom, Can you please clarify which version of Moodle you're using and how you applied the changes above? Cheers, Paul Edit: Also, please try purging Moodle's caches - your Moodle site may have (some of) the old JavaScript cached.
          Hide
          Tom Butkiewicz added a comment -

          Hi Paul,

          Currently on Moodle 2.3.1+ (Build: 20120823) Version 2012062501.11. - I think this may be my issue? Should I have tried this on 2.4 dev? If this is why, sorry about that!

          For ease of testing I replaced all 4 files with the ones from your commits listed.

          I purged all caches as well.

          Show
          Tom Butkiewicz added a comment - Hi Paul, Currently on Moodle 2.3.1+ (Build: 20120823) Version 2012062501.11. - I think this may be my issue? Should I have tried this on 2.4 dev? If this is why, sorry about that! For ease of testing I replaced all 4 files with the ones from your commits listed. I purged all caches as well.
          Hide
          Paul Nicholls added a comment -

          Hi Tom,
          That build should be fine, so long as you used the files from the MDL-34328_23 branch (there may be other changes in those files between your 2.3.1+ build and current 2.4dev). Do you get any errors/warnings/etc in the JS console (in Firebug or Chrome's dev tools, or the equivalent for whichever browser you're using)? It might also be worth purging your browser's cache, just to make sure it's not holding anything from before you purged Moodle's caches.

          -Paul

          Show
          Paul Nicholls added a comment - Hi Tom, That build should be fine, so long as you used the files from the MDL-34328 _23 branch (there may be other changes in those files between your 2.3.1+ build and current 2.4dev). Do you get any errors/warnings/etc in the JS console (in Firebug or Chrome's dev tools, or the equivalent for whichever browser you're using)? It might also be worth purging your browser's cache, just to make sure it's not holding anything from before you purged Moodle's caches. -Paul
          Hide
          Tom Butkiewicz added a comment -

          Hi Paul,

          Thanks for the quick response! No errors/warnings in the console for chrome tools. I'll continue messing around with it and reply with any updates!

          Show
          Tom Butkiewicz added a comment - Hi Paul, Thanks for the quick response! No errors/warnings in the console for chrome tools. I'll continue messing around with it and reply with any updates!
          Hide
          Andrew Nicols added a comment -

          Hi Paul,

          Sorry, but this is currently a -1 for me as it would break existing functionality - particularly with the toolboxes and drag/drop.

          With the toolbox JS, you've moved all of the code out of setup_for_resource() which will mean that any new resources created with AJAX (e.g. by drag/dropping files in) will not have the toolbox JS applied to them.
          It looks like you've done the same for the drag/drop code.

          Are we 100% certain that the JS and drag/drop code is what's causing these issues? I've so far been unable to replicate these issues correctly which makes it difficult for me to look into the cause fully – I'll try again if I can later today.

          If it is, it may be appropriate to keep the existing code in setup_for_resource, but use your code to handle the setup at the start. To do so, you'd need to not remove the content of _setup_for_resource(), stop calling setup_for_resource() in the initializer, and handle the show/hide and the groupmode attribute in the initializer too.

          I'm also not 100% sure on the use of the static $hasjs though I can see the purpose. It may be better to rewrite this as a YUI module which can only be instantiated once.

          Show
          Andrew Nicols added a comment - Hi Paul, Sorry, but this is currently a -1 for me as it would break existing functionality - particularly with the toolboxes and drag/drop. With the toolbox JS, you've moved all of the code out of setup_for_resource() which will mean that any new resources created with AJAX (e.g. by drag/dropping files in) will not have the toolbox JS applied to them. It looks like you've done the same for the drag/drop code. Are we 100% certain that the JS and drag/drop code is what's causing these issues? I've so far been unable to replicate these issues correctly which makes it difficult for me to look into the cause fully – I'll try again if I can later today. If it is, it may be appropriate to keep the existing code in setup_for_resource, but use your code to handle the setup at the start. To do so, you'd need to not remove the content of _setup_for_resource(), stop calling setup_for_resource() in the initializer, and handle the show/hide and the groupmode attribute in the initializer too. I'm also not 100% sure on the use of the static $hasjs though I can see the purpose. It may be better to rewrite this as a YUI module which can only be instantiated once.
          Hide
          Andrew Nicols added a comment - - edited

          I've produced an alternative fix which addresses the some issues with the toolbox efficiency.

          repository: http://git.luns.net.uk/moodle.git
          master branch: MDL-34328-master-1
          master diff: https://git.luns.net.uk/moodle.git/commitdiff/MDL-34328-master-1

          This does work with new resources created with drag/drop and has a massive effect on performance in IE.

          Looking at the call tree in IE, there are still some issues with the init_url_select (~265ms) - not least because it calls Y.use on each one.
          I do agree with the premise of Paul's patch to use delegate and only call Y.use() once, but I wonder if there may be a better way still of writing it.

          There are still some remaining issues with section, resource, and block drag/drop. I'll try and look into these shortly.

          Looking at the IE call tree, it also seems that there's something (wrapper -> Function.apply -> _createShim) is calling Y.later() over 30,000 times which has a time penatly of ~ 600ms on the qa.moodle.net course I backed up and restored.

          Show
          Andrew Nicols added a comment - - edited I've produced an alternative fix which addresses the some issues with the toolbox efficiency. repository: http://git.luns.net.uk/moodle.git master branch: MDL-34328 -master-1 master diff: https://git.luns.net.uk/moodle.git/commitdiff/MDL-34328-master-1 This does work with new resources created with drag/drop and has a massive effect on performance in IE. Looking at the call tree in IE, there are still some issues with the init_url_select (~265ms) - not least because it calls Y.use on each one. I do agree with the premise of Paul's patch to use delegate and only call Y.use() once, but I wonder if there may be a better way still of writing it. There are still some remaining issues with section, resource, and block drag/drop. I'll try and look into these shortly. Looking at the IE call tree, it also seems that there's something (wrapper -> Function.apply -> _createShim) is calling Y.later() over 30,000 times which has a time penatly of ~ 600ms on the qa.moodle.net course I backed up and restored.
          Hide
          Andrew Nicols added a comment -

          Attaching my before and after IE call trees for comparison.
          The initializer for the toolboxes was taking ~ 330ms
          It now takes ~ 12ms

          Show
          Andrew Nicols added a comment - Attaching my before and after IE call trees for comparison. The initializer for the toolboxes was taking ~ 330ms It now takes ~ 12ms
          Hide
          Andrew Nicols added a comment -

          Correcting attachment

          Show
          Andrew Nicols added a comment - Correcting attachment
          Hide
          James Henestofel added a comment -

          Not that this will really help with the issue. But I'm using 2.2.3 and recently started getting the Unresponsive errors only in IE8 and below. I can replicate the issue people are having here but we started getting it when I created over 1000 courses for our current term.

          I had the setting of "Course Limit" under Appearance and Navigation set to 1000. So whenever someone who didn't have a role in any course would login or do anything they would get the unresponsive error because it was trying to load 1000 courses for each category to display in the navigation. I've changed this to be 200 and it seems to work fine and I'm not getting the error anymore. I'm sure if I add more categories and courses I may have to limit even further.

          Show
          James Henestofel added a comment - Not that this will really help with the issue. But I'm using 2.2.3 and recently started getting the Unresponsive errors only in IE8 and below. I can replicate the issue people are having here but we started getting it when I created over 1000 courses for our current term. I had the setting of "Course Limit" under Appearance and Navigation set to 1000. So whenever someone who didn't have a role in any course would login or do anything they would get the unresponsive error because it was trying to load 1000 courses for each category to display in the navigation. I've changed this to be 200 and it seems to work fine and I'm not getting the error anymore. I'm sure if I add more categories and courses I may have to limit even further.
          Hide
          Andrew Nicols added a comment -

          james: I think that your issue is unrelated. The issues we're addressing in this issue are related to Moodle 2.3 and above when viewing a Course – these issues are all JavaScript related.

          From what I recall, we've hacked around the issue you're facing. I think that in our case, it was related to rendering all of the enrol icons on that page, but I may be wrong. We made a change in course/renderer.php to comment out the if ($icons = enrol_get_course_info_icons($course)) {}.

          Show
          Andrew Nicols added a comment - james: I think that your issue is unrelated. The issues we're addressing in this issue are related to Moodle 2.3 and above when viewing a Course – these issues are all JavaScript related. From what I recall, we've hacked around the issue you're facing. I think that in our case, it was related to rendering all of the enrol icons on that page, but I may be wrong. We made a change in course/renderer.php to comment out the if ($icons = enrol_get_course_info_icons($course)) {}.
          Hide
          Paul Nicholls added a comment -

          Hi Andrew,
          I haven't had a chance to look at your fix yet, but did you actually try mine out? The YUI dragdrop delegates are smart enough to pick up newly-added draggables, and I'm pretty sure that everything functioned correctly on resources created by dragging files into the browser.

          As for the Y.later() call from _createShim, I saw that but couldn't do anything about it without hacking core YUI code - but I'm not sure it was actually much of a problem, as it seemed to keep going on and on until you drag something - so the number of calls and the cumulative time in later() depends on how long you run the profiler for. The YUI hack may have resulted in the actual drag starting marginally faster, but it didn't seem to make enough of a difference anywhere (other than the numbers in the profiler) for me to bother proposing it.

          I'll take a look at your fix when I get a chance - I'm not in the office today, so it's a bit tricky right now.

          Show
          Paul Nicholls added a comment - Hi Andrew, I haven't had a chance to look at your fix yet, but did you actually try mine out? The YUI dragdrop delegates are smart enough to pick up newly-added draggables, and I'm pretty sure that everything functioned correctly on resources created by dragging files into the browser. As for the Y.later() call from _createShim, I saw that but couldn't do anything about it without hacking core YUI code - but I'm not sure it was actually much of a problem, as it seemed to keep going on and on until you drag something - so the number of calls and the cumulative time in later() depends on how long you run the profiler for. The YUI hack may have resulted in the actual drag starting marginally faster, but it didn't seem to make enough of a difference anywhere (other than the numbers in the profiler) for me to bother proposing it. I'll take a look at your fix when I get a chance - I'm not in the office today, so it's a bit tricky right now.
          Hide
          Paul Nicholls added a comment -

          Hi Andrew,
          I'm back in the office, and I've just had a look at your patch. I have a course which can reliably trigger the slow script warning on my setup - and I still get it with your patch.

          As I said in my previous comment, YUI's delegates are pretty smart, and should handle resources created by dragging files in without any trouble; it works fine for me, but if you're finding cases where it isn't, please let me know the details and I'll investigate.

          Show
          Paul Nicholls added a comment - Hi Andrew, I'm back in the office, and I've just had a look at your patch. I have a course which can reliably trigger the slow script warning on my setup - and I still get it with your patch. As I said in my previous comment, YUI's delegates are pretty smart, and should handle resources created by dragging files in without any trouble; it works fine for me, but if you're finding cases where it isn't, please let me know the details and I'll investigate.
          Hide
          Gregor McNish added a comment -

          We're having this problem as well. We've also seen an issue with IE where the browser becomes unresponsive just trying to enter a course without editing turned on-- the course in question has 40 topics. It does eventually get there (many minutes). With the open moodle docs in new window switched off, it takes about 3 minutes before the page is useable.
          We're recommending other browsers, but this isn't a great solution for many teachers who just want stuff to work like it did, without hassles...

          Show
          Gregor McNish added a comment - We're having this problem as well. We've also seen an issue with IE where the browser becomes unresponsive just trying to enter a course without editing turned on-- the course in question has 40 topics. It does eventually get there (many minutes). With the open moodle docs in new window switched off, it takes about 3 minutes before the page is useable. We're recommending other browsers, but this isn't a great solution for many teachers who just want stuff to work like it did, without hassles...
          Hide
          Paul Nijbakker added a comment -

          We tried the hacks in a test set up where it appeared to work, but when applied to a production environment it blocked the drag and drop and other functions. We are trying to find out why.

          Show
          Paul Nijbakker added a comment - We tried the hacks in a test set up where it appeared to work, but when applied to a production environment it blocked the drag and drop and other functions. We are trying to find out why.
          Hide
          Paul Nijbakker added a comment -

          I upgraded to the very latest release of 2.3.1 today. The upgrade itself did not fix the slow loading times. Then I applied the suggested fixes to the concerned files. Now drag and drop is not blocked anymore, but the slow loading of pages persists. In desperation I tried to turn drag and drop off totally, but I can't find where to do that.

          Show
          Paul Nijbakker added a comment - I upgraded to the very latest release of 2.3.1 today. The upgrade itself did not fix the slow loading times. Then I applied the suggested fixes to the concerned files. Now drag and drop is not blocked anymore, but the slow loading of pages persists. In desperation I tried to turn drag and drop off totally, but I can't find where to do that.
          Hide
          Jake Novak added a comment - - edited

          I can confirm this issue as well. We've seen it on IE 8 on XP SP3, and IE 9 (32 & 64 bit) on 7 64-bit. The changes have not made a noticeable difference, yet.

          Show
          Jake Novak added a comment - - edited I can confirm this issue as well. We've seen it on IE 8 on XP SP3, and IE 9 (32 & 64 bit) on 7 64-bit. The changes have not made a noticeable difference, yet.
          Hide
          Geoffrey Rowland added a comment -

          Also tried Paul Nicholl's patches on latest stable 2.3.1+
          Drag and drop still works (after all aches cleared). However, still getting 'A script on this page is causing Internet Explorer to run slowly etc' messages with IE8 after 'Turn editing on' is selected. Using a slightly tweaked Afterburner theme.

          Show
          Geoffrey Rowland added a comment - Also tried Paul Nicholl's patches on latest stable 2.3.1+ Drag and drop still works (after all aches cleared). However, still getting 'A script on this page is causing Internet Explorer to run slowly etc' messages with IE8 after 'Turn editing on' is selected. Using a slightly tweaked Afterburner theme.
          Hide
          Darren Bucknell added a comment -

          Can confirm these issues also.

          Upgraded to 2.3.1 from a clean install of 2.2. Painstakingly recreated all courses using Chrome and Firefox whilst teaching staff use IE8 and IE9.

          It is now almost impossible to use IE9 with the aforementioned issues all exhibited. We are looking to push out Chrome as a work-around though the Chrome also takes much longer than usual to be ready for editing.

          I notice that once the 'turn editing on' has been selected, the page refreshes and is not ready until the editing symbols have been populated correctly at each resource instance.

          Scrolling through a long course is erratic and editing in general seems much slower than normal.

          Show
          Darren Bucknell added a comment - Can confirm these issues also. Upgraded to 2.3.1 from a clean install of 2.2. Painstakingly recreated all courses using Chrome and Firefox whilst teaching staff use IE8 and IE9. It is now almost impossible to use IE9 with the aforementioned issues all exhibited. We are looking to push out Chrome as a work-around though the Chrome also takes much longer than usual to be ready for editing. I notice that once the 'turn editing on' has been selected, the page refreshes and is not ready until the editing symbols have been populated correctly at each resource instance. Scrolling through a long course is erratic and editing in general seems much slower than normal.
          Hide
          laurent added a comment -

          Hi,
          Same issue, browser is freezing when turning the editing mode on with Linux & browers : Debian Squeeze, Debian Wheezy, Ubuntu 10.10 et 11.10.
          Working fine on Windows (Vista, Seven, XP) / Mac (tested on Chrome, Firefox, Opera)

          Show
          laurent added a comment - Hi, Same issue, browser is freezing when turning the editing mode on with Linux & browers : Debian Squeeze, Debian Wheezy, Ubuntu 10.10 et 11.10. Working fine on Windows (Vista, Seven, XP) / Mac (tested on Chrome, Firefox, Opera)
          Hide
          Andrew Nicols added a comment - - edited

          Hi Paul,

          Sorry for not getting back to you sooner - I'm crazily busy at the moment.

          I haven't had a chance to test your patch yet, but if Y.Delegate does indeed act upon Nodes which haven't yet been created, then then your patch does indeed make sense (and I'm sure that it does now you mention it). Frustratingly, this is not mentioned in the documentation (http://yuilibrary.com/yui/docs/api/classes/Node.html#method_delegate), but then with YUI documentation, I guess that this is hardly surprising. I assume that it will only act upon Nodes created using YUI create functions and not with nodes created using native browser methods.

          As such, the changes to the toolbox code and the drag/drop code get my +1. I'm still less certain on the changes for outputrenderers.php, but I do agree that it does make sense and does make a massive difference to page performance. One other thought though – it may be worth applying the same delegation changes to:

          • section toolboxes
          • block drag/drop

          I've added Rajesh as maintainer of the AJAX component for his opinion on the changes to outputrenderers.php

          Thanks again for your hard work on this issue.

          Andrew

          Show
          Andrew Nicols added a comment - - edited Hi Paul, Sorry for not getting back to you sooner - I'm crazily busy at the moment. I haven't had a chance to test your patch yet, but if Y.Delegate does indeed act upon Nodes which haven't yet been created, then then your patch does indeed make sense (and I'm sure that it does now you mention it). Frustratingly, this is not mentioned in the documentation ( http://yuilibrary.com/yui/docs/api/classes/Node.html#method_delegate ), but then with YUI documentation, I guess that this is hardly surprising. I assume that it will only act upon Nodes created using YUI create functions and not with nodes created using native browser methods. As such, the changes to the toolbox code and the drag/drop code get my +1. I'm still less certain on the changes for outputrenderers.php, but I do agree that it does make sense and does make a massive difference to page performance. One other thought though – it may be worth applying the same delegation changes to: section toolboxes block drag/drop I've added Rajesh as maintainer of the AJAX component for his opinion on the changes to outputrenderers.php Thanks again for your hard work on this issue. Andrew
          Hide
          John Neeson added a comment -

          Just to add also experiencing these issues on our 2.3.1 Moodle install.

          Everything works fine and seems fairly speedy in Chrome (on W7 x64), however on IE8 & IE9 on W7 x64 we can't seem to use anything that needs javascript to work.

          Show
          John Neeson added a comment - Just to add also experiencing these issues on our 2.3.1 Moodle install. Everything works fine and seems fairly speedy in Chrome (on W7 x64), however on IE8 & IE9 on W7 x64 we can't seem to use anything that needs javascript to work.
          Hide
          Geoffrey Rowland added a comment -

          Tried this registry tweak to turn off the "A script on this page is causing Internet Explorer to run slowly" popup

          http://support.microsoft.com/kb/175500

          Worked (in the sense of no more popup) for IE 8 on Windows XP, but IE still very sluggish with Moodle 2.3.1+

          Show
          Geoffrey Rowland added a comment - Tried this registry tweak to turn off the "A script on this page is causing Internet Explorer to run slowly" popup http://support.microsoft.com/kb/175500 Worked (in the sense of no more popup) for IE 8 on Windows XP, but IE still very sluggish with Moodle 2.3.1+
          Hide
          Paul Nicholls added a comment -

          Hi Andrew,
          No worries - I'm very busy myself, trying to get as much done as possible before heading off on a month's holiday...

          I certainly considered applying the delegation to section toolboxes (and to a lesser extent to block drag/drop), but I haven't had time to do it myself - they don't seem to be taking up anywhere near as long as the bits I've already dealt with, though I guess that'll grow as the number of sections/blocks does; it's probably a good idea to do it to try to maintain consistent performance as possible no matter what size the course is.

          I've just about made it through everything on my list that I'm likely to be able to finish before I go, so I might be able to squeeze in a bit more time to work on this today and/or tomorrow.

          Show
          Paul Nicholls added a comment - Hi Andrew, No worries - I'm very busy myself, trying to get as much done as possible before heading off on a month's holiday... I certainly considered applying the delegation to section toolboxes (and to a lesser extent to block drag/drop), but I haven't had time to do it myself - they don't seem to be taking up anywhere near as long as the bits I've already dealt with, though I guess that'll grow as the number of sections/blocks does; it's probably a good idea to do it to try to maintain consistent performance as possible no matter what size the course is. I've just about made it through everything on my list that I'm likely to be able to finish before I go, so I might be able to squeeze in a bit more time to work on this today and/or tomorrow.
          Hide
          Paul Nicholls added a comment -

          New branches with additional patches (I rebased onto the latest master and MOODLE_23_STABLE - wasn't sure whether it was best to force-push to the same branches or create new ones, so I went with the latter). The additional patches are for section toolboxes and block drag/drop (including a fix for an already present bug which initiated a drag after showing/hiding a block - I could've split it into a separate tracker issue but I don't have time; it's related closely enough that I figure we can probably sneak it through here, as it was likely to be encountered during testing on this issue).

          I considered delegating the block show/hide and dock icons, but given that those icons are currently being generated on the fly in the JS anyway, I figure the overhead of creating them almost certainly eclipses the overhead of attaching individual click listeners to them (and it might also make delegating a bit trickier, since the elements don't exist until each one has been initialised anyway).

          On my test course, the extra patches do seem to make a bit of a difference, but it's hard to get a handle on it since IE's such an inconsistent beast (and its profiler is abysmal) - but I don't have a huge number of blocks or sections (~6 and ~12, respectively), so maybe the difference can be seen more clearly in courses with even more sections and/or blocks.

          Show
          Paul Nicholls added a comment - New branches with additional patches (I rebased onto the latest master and MOODLE_23_STABLE - wasn't sure whether it was best to force-push to the same branches or create new ones, so I went with the latter). The additional patches are for section toolboxes and block drag/drop (including a fix for an already present bug which initiated a drag after showing/hiding a block - I could've split it into a separate tracker issue but I don't have time; it's related closely enough that I figure we can probably sneak it through here, as it was likely to be encountered during testing on this issue). I considered delegating the block show/hide and dock icons, but given that those icons are currently being generated on the fly in the JS anyway, I figure the overhead of creating them almost certainly eclipses the overhead of attaching individual click listeners to them (and it might also make delegating a bit trickier, since the elements don't exist until each one has been initialised anyway). On my test course, the extra patches do seem to make a bit of a difference, but it's hard to get a handle on it since IE's such an inconsistent beast (and its profiler is abysmal) - but I don't have a huge number of blocks or sections (~6 and ~12, respectively), so maybe the difference can be seen more clearly in courses with even more sections and/or blocks.
          Hide
          Geoffrey Rowland added a comment -

          Hi Paul

          Thanks for all your work on this. Have tried your latest patches on Moodle 2.3.1+ and they do seem to make a difference. Previously a large (40 topic) course was throwing up script timeout popups in edit mode using IE8. After the patches is not. I think things are mnoticeably faster in Firefox, Chrome and Opera too, though havn't done any detailed benchmarking and there are lots of other areas.

          Still have a bigger (in terms of users, logs, courses and course content) Moodle 2.3.1+ instance (upgraded from 1.9) with the same patches applied which is still struggling with IE8. Very sluggish performance and script timeouts being thrown up, even when not editing. Some of the problem may be that we are currently locked into Compatibility View for IE8. Still investigating other reasons such as theme, blocks, filters and JavaScript that may be responsible for very poor performance.

          Show
          Geoffrey Rowland added a comment - Hi Paul Thanks for all your work on this. Have tried your latest patches on Moodle 2.3.1+ and they do seem to make a difference. Previously a large (40 topic) course was throwing up script timeout popups in edit mode using IE8. After the patches is not. I think things are mnoticeably faster in Firefox, Chrome and Opera too, though havn't done any detailed benchmarking and there are lots of other areas. Still have a bigger (in terms of users, logs, courses and course content) Moodle 2.3.1+ instance (upgraded from 1.9) with the same patches applied which is still struggling with IE8. Very sluggish performance and script timeouts being thrown up, even when not editing. Some of the problem may be that we are currently locked into Compatibility View for IE8. Still investigating other reasons such as theme, blocks, filters and JavaScript that may be responsible for very poor performance.
          Hide
          Paul Nicholls added a comment -

          Hi Geoffrey,
          Thanks for your feedback. Is there any chance you could give me access to a course or two that are still suffering badly (i.e. the ones which are still hitting script timeouts), so I can dig a bit deeper? Everything I've done so far has been based on performance in a couple of courses on my dev sites, so it'd be very helpful to have more examples of sluggish courses (particularly any that are still hitting script timeouts with the patches applied). That said, unless you happen to be around within the next few hours, I won't have a chance to look at it for a month or so - but hopefully somebody else (Andrew? Rajesh?) can take over.

          Show
          Paul Nicholls added a comment - Hi Geoffrey, Thanks for your feedback. Is there any chance you could give me access to a course or two that are still suffering badly (i.e. the ones which are still hitting script timeouts), so I can dig a bit deeper? Everything I've done so far has been based on performance in a couple of courses on my dev sites, so it'd be very helpful to have more examples of sluggish courses (particularly any that are still hitting script timeouts with the patches applied). That said, unless you happen to be around within the next few hours, I won't have a chance to look at it for a month or so - but hopefully somebody else (Andrew? Rajesh?) can take over.
          Hide
          John Neeson added a comment -

          Hi Paul,

          Thanks for submitting the patch. I've just tried it on our 2.3.1+ install (latest weekly git pull) and I was still getting script timeout errors on our courses (we get the errors even with editing turned off!) with IE8 on W7 x64.

          I also then tried Chrome on the same PC and found that I couldn't activate the drag and drop interface.

          Reverting to the 2.3.1+ latest weekly and I can now drag and drop using Chrome. IE is still causing issues.

          If anyone needs access to some courses to test it with I'm able to give you access to ours. We'd really like to get this bug squashed as our staff love this feature, so anything we can do to help please let me know!

          Thanks,

          John

          Show
          John Neeson added a comment - Hi Paul, Thanks for submitting the patch. I've just tried it on our 2.3.1+ install (latest weekly git pull) and I was still getting script timeout errors on our courses (we get the errors even with editing turned off!) with IE8 on W7 x64. I also then tried Chrome on the same PC and found that I couldn't activate the drag and drop interface. Reverting to the 2.3.1+ latest weekly and I can now drag and drop using Chrome. IE is still causing issues. If anyone needs access to some courses to test it with I'm able to give you access to ours. We'd really like to get this bug squashed as our staff love this feature, so anything we can do to help please let me know! Thanks, John
          Hide
          Geoffrey Rowland added a comment -

          Hi folks

          Was getting a bit desperate with the start of term looming, so have been pretty ruthless doing anything to reduce page load times on our Moodle 2.3.1+ instances (which happen to be on the same server). Had already applied the patches (to be precise, just replaced the 5 altered files from the Git Pull 2.3 Diff URL, above) which, in our hands, do still allow drag-and-drop upload (Firefox and Chrome tested).

          As noted in my previous post, this nicely fixed one instance which was sluggish and throwing up 'A script on this page...' errors when editing with IE8. This instance was relatively new, starting out as a 2.1 upgraded via 2.2 to 2.3, with not too many courses.

          Our other larger Moodle, that had been upgraded from 1.9 to 2.2 to 2.3 was virtually unusable with IE8, even after patching, generating 'A script on this page...' errors with IE, even when not editing

          Have just found that turning off Show all courses (navshowallcourses)in Settings > Site administration > Navigation fixed the IE8 issues and made our site 'lightning' fast.

          So, I presume the Category and Course structure of our old big Moodle was just too much. Perhaps a 'tipping point' where page load times trigger the IE8 messages. This may explain why the different 'solutions' suggested in this forum may work in different contexts.

          Show
          Geoffrey Rowland added a comment - Hi folks Was getting a bit desperate with the start of term looming, so have been pretty ruthless doing anything to reduce page load times on our Moodle 2.3.1+ instances (which happen to be on the same server). Had already applied the patches (to be precise, just replaced the 5 altered files from the Git Pull 2.3 Diff URL, above) which, in our hands, do still allow drag-and-drop upload (Firefox and Chrome tested). As noted in my previous post, this nicely fixed one instance which was sluggish and throwing up 'A script on this page...' errors when editing with IE8. This instance was relatively new, starting out as a 2.1 upgraded via 2.2 to 2.3, with not too many courses. Our other larger Moodle, that had been upgraded from 1.9 to 2.2 to 2.3 was virtually unusable with IE8, even after patching, generating 'A script on this page...' errors with IE, even when not editing Have just found that turning off Show all courses (navshowallcourses)in Settings > Site administration > Navigation fixed the IE8 issues and made our site 'lightning' fast. So, I presume the Category and Course structure of our old big Moodle was just too much. Perhaps a 'tipping point' where page load times trigger the IE8 messages. This may explain why the different 'solutions' suggested in this forum may work in different contexts.
          Hide
          Geoffrey Rowland added a comment -

          That should be...

          Have just found that turning off Show all courses (navshowallcourses)in Settings > Site administration > Appearance > Navigation fixed the IE8 issues and made our site 'lightning' fast.

          Show
          Geoffrey Rowland added a comment - That should be... Have just found that turning off Show all courses (navshowallcourses)in Settings > Site administration > Appearance > Navigation fixed the IE8 issues and made our site 'lightning' fast.
          Hide
          Michael Woods added a comment -

          Hi Geoffrey,

          Thanks for your comments. Our site was also a very large 1.9.x site with many nested categories and sub-categories. Interestingly, we had the 'Show all courses' not ticked from the very start and still experienced many problems, mainly in IE8/IE9. The biggest single performance improver was turning off the 'Moodle docs in new window' setting.

          My testing indicates that the slow performance is almost purely a function of the number of topics in a course, not the number of resources. Try loading up a course with 400 resources but only 1 topic, then compare the performance to a completely blank course with 50 topics - the more topics, the worse it is across all browsers, but particularly IE.

          Thanks to everyone who is working hard on this issue!

          Regards,
          Michael

          Show
          Michael Woods added a comment - Hi Geoffrey, Thanks for your comments. Our site was also a very large 1.9.x site with many nested categories and sub-categories. Interestingly, we had the 'Show all courses' not ticked from the very start and still experienced many problems, mainly in IE8/IE9. The biggest single performance improver was turning off the 'Moodle docs in new window' setting. My testing indicates that the slow performance is almost purely a function of the number of topics in a course, not the number of resources. Try loading up a course with 400 resources but only 1 topic, then compare the performance to a completely blank course with 50 topics - the more topics, the worse it is across all browsers, but particularly IE. Thanks to everyone who is working hard on this issue! Regards, Michael
          Hide
          Geoffrey Rowland added a comment -

          Hi Michael

          We have never had Moodle docs in new window switched on, but still had IE8 issues.

          We do now have Paul's patch applied, which should help with the topics issue. Indeed this stopped IE8 issues (sluggishness and Slow script popup) when editing courses with 40+ topics on one of our Moodle instances.

          After this, turning off Show all courses resolved things on our larger, more problematic Moodle which had IE8 issues even without being in edit mode. Turn it back on, and the IE8 issues returned.

          Have just tried turning Moodle docs in new window on, and can confirm IE8 issues appear (So, have quickly turned it off again!).

          So, looks as if there is more than one factor, or combination of factors, that can trigger these symptoms.

          Show
          Geoffrey Rowland added a comment - Hi Michael We have never had Moodle docs in new window switched on, but still had IE8 issues. We do now have Paul's patch applied, which should help with the topics issue. Indeed this stopped IE8 issues (sluggishness and Slow script popup) when editing courses with 40+ topics on one of our Moodle instances. After this, turning off Show all courses resolved things on our larger, more problematic Moodle which had IE8 issues even without being in edit mode. Turn it back on, and the IE8 issues returned. Have just tried turning Moodle docs in new window on, and can confirm IE8 issues appear (So, have quickly turned it off again!). So, looks as if there is more than one factor, or combination of factors, that can trigger these symptoms.
          Hide
          Paul Nijbakker added a comment - - edited

          Thanks Michael and Geoffrey,

          We upgraded to the latest release of Moodle 2.3.1 last weekend, which already improved loading time of a test course (with maximum topics) in Firefox from 20 to 14 seconds (I.E.1.9 still got stuck). After turning off the Moodle docs in new window (such an innocuous-looking setting!) the loading time improved to under 4 seconds in Firefox and to 35 seconds in I.E. (still better than getting totally stuck).

          We are looking forward to further improvements, but this seems to have been the big culprit in our case (Show all courses was never turned on).

          Show
          Paul Nijbakker added a comment - - edited Thanks Michael and Geoffrey, We upgraded to the latest release of Moodle 2.3.1 last weekend, which already improved loading time of a test course (with maximum topics) in Firefox from 20 to 14 seconds (I.E.1.9 still got stuck). After turning off the Moodle docs in new window (such an innocuous-looking setting!) the loading time improved to under 4 seconds in Firefox and to 35 seconds in I.E. (still better than getting totally stuck). We are looking forward to further improvements, but this seems to have been the big culprit in our case (Show all courses was never turned on).
          Hide
          Tom Butkiewicz added a comment -

          I believe I have found an issue regarding the patch listed. Although Paul's latest patch seems to work the best at speeding up the load time, it looks like it broke drag/drops sticking.

          Using latest version of Google Chrome.

          Steps I took:

          1. Applied Paul's changes listed here (https://github.com/pauln/moodle/compare/MOODLE_23_STABLE...MDL-34328_23_2) to a base moodle installation (https://github.com/moodle/moodle/tree/MOODLE_23_STABLE).
          2. Flushed Moodle cache
          3. Cleared all Browser caches
          4. Created 2 Assignments and 2 Labels
          5. Moved the assignments up/down
          6. Moved the labels up/down
          7. Refresh browser page
          8. Assignments/labels are back at their original position pre-patch.

          Note: it seems like the very first move works, I'm not sure why, but consecutive moves after do not stick. Also, the loading swirly that shows to the right of the assignments/labels after drag-drop does not seem to appear anymore.

          To help explain the issue, I have created a ~50 sec video to show the above actions on screen. http://www.youtube.com/watch?v=wXneAIim0FA

          Does anyone else have this issue after applying the patch?

          Show
          Tom Butkiewicz added a comment - I believe I have found an issue regarding the patch listed. Although Paul's latest patch seems to work the best at speeding up the load time, it looks like it broke drag/drops sticking. Using latest version of Google Chrome. Steps I took: Applied Paul's changes listed here ( https://github.com/pauln/moodle/compare/MOODLE_23_STABLE...MDL-34328_23_2 ) to a base moodle installation ( https://github.com/moodle/moodle/tree/MOODLE_23_STABLE ). Flushed Moodle cache Cleared all Browser caches Created 2 Assignments and 2 Labels Moved the assignments up/down Moved the labels up/down Refresh browser page Assignments/labels are back at their original position pre-patch. Note : it seems like the very first move works, I'm not sure why, but consecutive moves after do not stick. Also, the loading swirly that shows to the right of the assignments/labels after drag-drop does not seem to appear anymore. To help explain the issue, I have created a ~50 sec video to show the above actions on screen. http://www.youtube.com/watch?v=wXneAIim0FA Does anyone else have this issue after applying the patch?
          Hide
          Paul Nijbakker added a comment - - edited

          @Tom,

          Yes, actually we do have similar issues, but we did not suspect the patch. It would make sense, however, the behaviour is not as clear cut.

          Show
          Paul Nijbakker added a comment - - edited @Tom, Yes, actually we do have similar issues, but we did not suspect the patch. It would make sense, however, the behaviour is not as clear cut.
          Hide
          Christopher Brower added a comment -

          We are another site experiencing the same issues and was just wondering if the developers have an ETA on a patch being included in a development or stable release?

          Show
          Christopher Brower added a comment - We are another site experiencing the same issues and was just wondering if the developers have an ETA on a patch being included in a development or stable release?
          Hide
          Andrew Nicols added a comment -

          Taking a look at these drag/drop issues. It appears that the browser doesn't always catch the drag_dropmiss event. If you carefully move it, then it does seem to work. I'm not quite sure how this patchset has this consequence. Looking further.

          Show
          Andrew Nicols added a comment - Taking a look at these drag/drop issues. It appears that the browser doesn't always catch the drag_dropmiss event. If you carefully move it, then it does seem to work. I'm not quite sure how this patchset has this consequence. Looking further.
          Hide
          Andrew Nicols added a comment -

          This drag/drop issue is an unrelated bug which affects drop miss events. I've got a patch which fixes it. I'll finish testing all of Paul's changes and incorporate it all together.

          Show
          Andrew Nicols added a comment - This drag/drop issue is an unrelated bug which affects drop miss events. I've got a patch which fixes it. I'll finish testing all of Paul's changes and incorporate it all together.
          Hide
          Andrew Nicols added a comment -

          I've added a minor change to address one issue in Paul's absence.

          Show
          Andrew Nicols added a comment - I've added a minor change to address one issue in Paul's absence.
          Hide
          Andrew Nicols added a comment -

          Submitting for integration.
          I've peer reviewed this and am happy with the changes. The only one which may warrant some further thought is the change to the dropdown menus - a worthwhile change, but others may have specific views on it.

          Show
          Andrew Nicols added a comment - Submitting for integration. I've peer reviewed this and am happy with the changes. The only one which may warrant some further thought is the change to the dropdown menus - a worthwhile change, but others may have specific views on it.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Side comment: This will be integrated next week (current one is over). Just anticipating how unrelated the title of the issue and the testing instructions seem to be. Is there any way to check that the original problem (browser slowdown) gets fixed with the patch?

          Please, add it to instructions if possible. It seems that instructions only are covering regression testing.

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Side comment: This will be integrated next week (current one is over). Just anticipating how unrelated the title of the issue and the testing instructions seem to be. Is there any way to check that the original problem (browser slowdown) gets fixed with the patch? Please, add it to instructions if possible. It seems that instructions only are covering regression testing.
          Hide
          Melissa Benson added a comment -

          Is this for IE only?

          Show
          Melissa Benson added a comment - Is this for IE only?
          Hide
          Justin Gomes added a comment -

          Hello,

          After replacing the 5 files we received reports that the tinymce editor was only showing HTML code and category.php was giving an error. The tinymce problem appeared after clearing the browser cache.

          We turned on debugging and pulled the following stack trace from category.php:

          Coding error detected, it must be fixed by a programmer: PHP catchable fatal error

          More information about this error

          Debug info: Argument 4 passed to html_writer::label() must be an array, null given, called in D:\moodle\lib\outputrenderers.php on line 1335 and defined

          Error code: codingerror

          Stack trace: ◦line 397 of \lib\setuplib.php: coding_exception thrown

          ◦line 1679 of \lib\outputcomponents.php: call to default_error_handler()
          ◦line 1335 of \lib\outputrenderers.php: call to html_writer::label()
          ◦line 101 of \lib\outputrenderers.php: call to core_renderer->render_single_select()
          ◦line 210 of \course\category.php: call to renderer_base->render()

          Show
          Justin Gomes added a comment - Hello, After replacing the 5 files we received reports that the tinymce editor was only showing HTML code and category.php was giving an error. The tinymce problem appeared after clearing the browser cache. We turned on debugging and pulled the following stack trace from category.php: Coding error detected, it must be fixed by a programmer: PHP catchable fatal error More information about this error Debug info: Argument 4 passed to html_writer::label() must be an array, null given, called in D:\moodle\lib\outputrenderers.php on line 1335 and defined Error code: codingerror Stack trace: ◦line 397 of \lib\setuplib.php: coding_exception thrown ◦line 1679 of \lib\outputcomponents.php: call to default_error_handler() ◦line 1335 of \lib\outputrenderers.php: call to html_writer::label() ◦line 101 of \lib\outputrenderers.php: call to core_renderer->render_single_select() ◦line 210 of \course\category.php: call to renderer_base->render()
          Hide
          Paul Nijbakker added a comment -

          @Eloy,
          Indeed, fixing the frag drop issue on the course page is great, but the browser slowdown/page-loading issue is more serious. It seriously interferes with the Moodle experience of all users (not just the teachers and admins).

          Show
          Paul Nijbakker added a comment - @Eloy, Indeed, fixing the frag drop issue on the course page is great, but the browser slowdown/page-loading issue is more serious. It seriously interferes with the Moodle experience of all users (not just the teachers and admins).
          Hide
          Cathal O'Riordan added a comment -

          A possible interim solution is to request your IE 8 & 9 users to install Google Chrome Frame, https://developers.google.com/chrome/chrome-frame/ . Replacing the rendering engine in IE with Google Chrome seems to speed up the page rending speed vastly, particularly in the case of the core problem reported in this bug. I have tested this on our Moodle 2.3.2+ site with IE 8. I'm also happy to say that the filepicker drag and drop feature which isn't present in IE 8, can be used when Googhe Chrome Frame is used.

          Show
          Cathal O'Riordan added a comment - A possible interim solution is to request your IE 8 & 9 users to install Google Chrome Frame, https://developers.google.com/chrome/chrome-frame/ . Replacing the rendering engine in IE with Google Chrome seems to speed up the page rending speed vastly, particularly in the case of the core problem reported in this bug. I have tested this on our Moodle 2.3.2+ site with IE 8. I'm also happy to say that the filepicker drag and drop feature which isn't present in IE 8, can be used when Googhe Chrome Frame is used.
          Hide
          Andrew Nicols added a comment -

          @Eloy: I'll try and get round to them this afternoon/tomorrow
          @Melissa: No - it will also improve performance in other browsers, but IE is where it sucks the most
          @Justin: It's not designed to be a drop-in replacement. You need to apply the patches. Other changes have been made in these areas which will interfere with these patches
          @Paul Nicbakker: Not sure what you mean - perhaps you could clarify?

          Show
          Andrew Nicols added a comment - @Eloy: I'll try and get round to them this afternoon/tomorrow @Melissa: No - it will also improve performance in other browsers, but IE is where it sucks the most @Justin: It's not designed to be a drop-in replacement. You need to apply the patches. Other changes have been made in these areas which will interfere with these patches @Paul Nicbakker: Not sure what you mean - perhaps you could clarify?
          Hide
          Petr Škoda added a comment -

          Hi, could somebody try YUI3.7.0 from MDL-35515, they say it should be faster compared to 3.6.0.

          Show
          Petr Škoda added a comment - Hi, could somebody try YUI3.7.0 from MDL-35515 , they say it should be faster compared to 3.6.0.
          Hide
          Paul Nijbakker added a comment -

          @Andrew,
          I was referring to Eloy's message that the testing instructions seem to address a side issue to the main problem, namely the issues with dragging and dropping on the course page, while the main problem in the description of the tracker issue is the slowness of the browser. Perhaps, your patch fixes both (that would be great), but that does not become clear from the testing instructions.

          Show
          Paul Nijbakker added a comment - @Andrew, I was referring to Eloy's message that the testing instructions seem to address a side issue to the main problem, namely the issues with dragging and dropping on the course page, while the main problem in the description of the tracker issue is the slowness of the browser. Perhaps, your patch fixes both (that would be great), but that does not become clear from the testing instructions.
          Hide
          Dan Poltawski added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Paul Nicholls added a comment -

          Eloy, the testing instructions I put in are indeed effectively regression tests - covering areas I touched. The changes should make no change to functionality or behaviour, only to performance; the difference is mostly noticeable in IE8 (particularly so on slower computers - colleagues at another university told me that they had users reporting issues, but they couldn't replicate them on their powerful developer machines, even when using the same versions of Windows and IE!). Other than saying "does it seem snappier?" I'm not sure how to capture performance improvements like this in testing instructions.

          -Paul

          P.S. I'm still on holiday - just popping in briefly during a spot of otherwise free time; thanks, Andrew, for looking into the drop miss issue in my absence!)

          Show
          Paul Nicholls added a comment - Eloy, the testing instructions I put in are indeed effectively regression tests - covering areas I touched. The changes should make no change to functionality or behaviour, only to performance; the difference is mostly noticeable in IE8 (particularly so on slower computers - colleagues at another university told me that they had users reporting issues, but they couldn't replicate them on their powerful developer machines, even when using the same versions of Windows and IE!). Other than saying "does it seem snappier?" I'm not sure how to capture performance improvements like this in testing instructions. -Paul P.S. I'm still on holiday - just popping in briefly during a spot of otherwise free time; thanks, Andrew, for looking into the drop miss issue in my absence!)
          Hide
          Andrew Nicols added a comment -

          I've dropped the add menu patches from all branches because MDL-30912 changes the existing usage of the dropdown boxes and opened a new issue - MDL-35569 to look at addressing these potential issues.

          Show
          Andrew Nicols added a comment - I've dropped the add menu patches from all branches because MDL-30912 changes the existing usage of the dropdown boxes and opened a new issue - MDL-35569 to look at addressing these potential issues.
          Hide
          Dan Poltawski added a comment -

          Hi Andrew,

          Are you able to rebase this. Its conflicting on master.

          Show
          Dan Poltawski added a comment - Hi Andrew, Are you able to rebase this. Its conflicting on master.
          Hide
          Andrew Nicols added a comment -

          This was already rebased against latest weeklies. I've just rebased against integration's master without any conflicts.

          Pushed latest version

          Show
          Andrew Nicols added a comment - This was already rebased against latest weeklies. I've just rebased against integration's master without any conflicts. Pushed latest version
          Hide
          Andrew Nicols added a comment -

          Just seeing the diff, I realise I must not have updated the branch names on the tracker last week - my browser crashed mid-way through my update of this issue and I must have missed it. Apologies.

          Show
          Andrew Nicols added a comment - Just seeing the diff, I realise I must not have updated the branch names on the tracker last week - my browser crashed mid-way through my update of this issue and I must have missed it. Apologies.
          Hide
          Dan Poltawski added a comment -

          Thanks a lot Paul & Andrew for your work on this issue.

          In my brief testing things are looking a lot snappier!

          Show
          Dan Poltawski added a comment - Thanks a lot Paul & Andrew for your work on this issue. In my brief testing things are looking a lot snappier!
          Hide
          Dan Poltawski added a comment -

          I've integrated this to 23 and master. Heres hoping testing verifies the fix!

          Show
          Dan Poltawski added a comment - I've integrated this to 23 and master. Heres hoping testing verifies the fix!
          Hide
          Vicki Dunnam added a comment -

          The unresponsive behavior also happens in Firefox and Chrome. We are having major issues with is issue in our Moodle instance 2.3.2+

          Show
          Vicki Dunnam added a comment - The unresponsive behavior also happens in Firefox and Chrome. We are having major issues with is issue in our Moodle instance 2.3.2+
          Hide
          Michael de Raadt added a comment -

          Test result: Failed.

          I'm sorry, but even with these changes I'm still seeing massive load in IE8 and IE9, even after the page is seemingly loaded. It might be that there are multiple problems here.

          From what I can tell, the JS is stuck in a loop that is continuing indefinitely. I'm not sure why IE is not shutting that JS down.

          I will attach a screenshot that shows the guilty functions.

          Show
          Michael de Raadt added a comment - Test result: Failed. I'm sorry, but even with these changes I'm still seeing massive load in IE8 and IE9, even after the page is seemingly loaded. It might be that there are multiple problems here. From what I can tell, the JS is stuck in a loop that is continuing indefinitely. I'm not sure why IE is not shutting that JS down. I will attach a screenshot that shows the guilty functions.
          Hide
          Andrew Nicols added a comment -

          Hi Michael,

          The changes so far should be an improvement, but I think that the biggest culprit is actually the dropdowns I mentioned above and have opened a new issue for (MDL-35569). Paul had hoped to address those in this issue, but they've been completely re-written last week in MDL-30912 so we skipped them from this changeset to work on them separately.

          From my discussions with Paul Nicholls, we believe that the _createShim() function you highlight above is a red herring:

          As for the Y.later() call from _createShim, I saw that but couldn't do anything about it without hacking core YUI code - but I'm not sure it was actually much of a problem, as it seemed to keep going on and on until you drag something - so the number of calls and the cumulative time in later() depends on how long you run the profiler for. The YUI hack may have resulted in the actual drag starting marginally faster, but it didn't seem to make enough of a difference anywhere (other than the numbers in the profiler) for me to bother proposing it.

          Any chance I could have a copy of the profile you generated?

          Show
          Andrew Nicols added a comment - Hi Michael, The changes so far should be an improvement, but I think that the biggest culprit is actually the dropdowns I mentioned above and have opened a new issue for ( MDL-35569 ). Paul had hoped to address those in this issue, but they've been completely re-written last week in MDL-30912 so we skipped them from this changeset to work on them separately. From my discussions with Paul Nicholls, we believe that the _createShim() function you highlight above is a red herring: As for the Y.later() call from _createShim, I saw that but couldn't do anything about it without hacking core YUI code - but I'm not sure it was actually much of a problem, as it seemed to keep going on and on until you drag something - so the number of calls and the cumulative time in later() depends on how long you run the profiler for. The YUI hack may have resulted in the actual drag starting marginally faster, but it didn't seem to make enough of a difference anywhere (other than the numbers in the profiler) for me to bother proposing it. Any chance I could have a copy of the profile you generated?
          Hide
          Chris Meyer added a comment -

          Here's a link to the 10 most common slowdowns for Javascript. Maybe it helps.

          http://blog.dynatrace.com/2010/08/25/top-10-client-side-performance-problems-in-web-2-0/

          Show
          Chris Meyer added a comment - Here's a link to the 10 most common slowdowns for Javascript. Maybe it helps. http://blog.dynatrace.com/2010/08/25/top-10-client-side-performance-problems-in-web-2-0/
          Hide
          Michael de Raadt added a comment -

          Thanks for following up on this guys.

          The load created by this _createShim call seems significant. It was consuming about 80% of my CPU after the page had loaded and all had settled down. If we can fix that issue, that would be great.

          But that's probably not the only problem. I think we need to get specific about the causes of this unresponsive behaviour, and break this down into sub-tasks.

          I will attach the profile from when the page was loading and one generated over a couple of seconds well after the page had loaded.

          Show
          Michael de Raadt added a comment - Thanks for following up on this guys. The load created by this _createShim call seems significant. It was consuming about 80% of my CPU after the page had loaded and all had settled down. If we can fix that issue, that would be great. But that's probably not the only problem. I think we need to get specific about the causes of this unresponsive behaviour, and break this down into sub-tasks. I will attach the profile from when the page was loading and one generated over a couple of seconds well after the page had loaded.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          +1 to reopen this but keeping current commit not-reverted, as far as they:

          • don't cause any regression.
          • make things slightly better, although they are not the complete solution.

          Ciao

          PS: I'd recommend to create some place/site where the problem is reproducible always. In a constant way. This just has way too many reports, each one corresponding to a different site, course, sizes... IMO we should have one well-defined-and-stable case somewhere, so any performance improv. can be measured properly. Else, it all sounds like "vapor" (not saying people here is not experimenting the problems, just suggesting we need it reproduced constantly to be able to compare any solution).

          Show
          Eloy Lafuente (stronk7) added a comment - - edited +1 to reopen this but keeping current commit not-reverted, as far as they: don't cause any regression. make things slightly better, although they are not the complete solution. Ciao PS: I'd recommend to create some place/site where the problem is reproducible always. In a constant way. This just has way too many reports, each one corresponding to a different site, course, sizes... IMO we should have one well-defined-and-stable case somewhere, so any performance improv. can be measured properly. Else, it all sounds like "vapor" (not saying people here is not experimenting the problems, just suggesting we need it reproduced constantly to be able to compare any solution).
          Hide
          Derek Chirnside added a comment -

          Guys, hang in there. I can't help at all. It reminds me of the cartoon my son had. Picture 1 of a coder on Monday. "It's broke, and I don't know why" Picture of same coder on a Tuesday. "It's working, and I don't know why"

          Show
          Derek Chirnside added a comment - Guys, hang in there. I can't help at all. It reminds me of the cartoon my son had. Picture 1 of a coder on Monday. "It's broke, and I don't know why" Picture of same coder on a Tuesday. "It's working, and I don't know why"
          Hide
          Dan Poltawski added a comment -

          Ok, so we are taking the highly unusual step of reopening this issue, but keeping the current code integrated.

          As far as we can tell, there aren't regressions introduced by this change, but it does not resolve the originally reported issue, so it would not be right to close this issue.

          There is a lot of discussion in this issue, and it may perhaps be worth breaking down into small measurable improvements as a subtasks which we can test individually.

          Really, it does feel like things the docs link setting making a difference indicate something very odd going on here..

          Show
          Dan Poltawski added a comment - Ok, so we are taking the highly unusual step of reopening this issue, but keeping the current code integrated. As far as we can tell, there aren't regressions introduced by this change, but it does not resolve the originally reported issue, so it would not be right to close this issue. There is a lot of discussion in this issue, and it may perhaps be worth breaking down into small measurable improvements as a subtasks which we can test individually. Really, it does feel like things the docs link setting making a difference indicate something very odd going on here..
          Hide
          Tim Hunt added a comment -

          I pointed out another JS perf issue, and Andrew Nichols said he might fix it if I created the tracker issue. Therefore, as suggested above, I created a JS performance meta-bug: MDL-35672.

          Show
          Tim Hunt added a comment - I pointed out another JS perf issue, and Andrew Nichols said he might fix it if I created the tracker issue. Therefore, as suggested above, I created a JS performance meta-bug: MDL-35672 .
          Hide
          Dan Poltawski added a comment -

          Eloy: the reproducible case for this is as Michael reported, the Moodle features demo on IE8.

          Show
          Dan Poltawski added a comment - Eloy: the reproducible case for this is as Michael reported, the Moodle features demo on IE8.
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Vicki Dunnam added a comment -

          This is a MAJOR issue!! I am having problems using Firefox, IE, Chrome. When trying to create a quiz and click SAVE and DISPLAY, the browser become unresponsive. When trying to turn the eye from closed to open, causes slow response from browser!! This is a very bad situation. We are using Moodle 2.3.+ (build 20120920) We do have large courses. Anything I can do to help or give data to help resolve.... let me know.

          Show
          Vicki Dunnam added a comment - This is a MAJOR issue!! I am having problems using Firefox, IE, Chrome. When trying to create a quiz and click SAVE and DISPLAY, the browser become unresponsive. When trying to turn the eye from closed to open, causes slow response from browser!! This is a very bad situation. We are using Moodle 2.3.+ (build 20120920) We do have large courses. Anything I can do to help or give data to help resolve.... let me know.
          Hide
          curt bixel added a comment -

          I don't know enough about all of this to know if the following information is useful or not.

          I was running a moodle quiz in my class yesterday. In the first 3 classes, moodle 2.3 worked great. In the 4th class, I attempted to enroll a student in moodle. This seemed to tank the quiz for every single student in class regardless of the method of access. Some were using Safari, some Firefox, some Chrome, some Android, some iPhone.. Some were using the schools wireless network, some were connecting using there cell phones.

          After I logged off, the problem went away. Logged on again as admin to do something else, pretty much every student in the class called out "its not working" in unison.

          Hope this information is of some use, as it points to the problem being with the moodle software on the server.

          (By the way, I did a ping test on the server and a "route" check, and it appears that the server is working well.)

          Show
          curt bixel added a comment - I don't know enough about all of this to know if the following information is useful or not. I was running a moodle quiz in my class yesterday. In the first 3 classes, moodle 2.3 worked great. In the 4th class, I attempted to enroll a student in moodle. This seemed to tank the quiz for every single student in class regardless of the method of access. Some were using Safari, some Firefox, some Chrome, some Android, some iPhone.. Some were using the schools wireless network, some were connecting using there cell phones. After I logged off, the problem went away. Logged on again as admin to do something else, pretty much every student in the class called out "its not working" in unison. Hope this information is of some use, as it points to the problem being with the moodle software on the server. (By the way, I did a ping test on the server and a "route" check, and it appears that the server is working well.)
          Hide
          Paul Nicholls added a comment -

          Curt, that sounds like an unrelated issue - this is about client-side (JavaScript) performance issues, primarily in IE8. If you can't find an existing issue in the tracker which matches your issue, please report it as a new issue so that it can be investigated properly.

          Show
          Paul Nicholls added a comment - Curt, that sounds like an unrelated issue - this is about client-side (JavaScript) performance issues, primarily in IE8. If you can't find an existing issue in the tracker which matches your issue, please report it as a new issue so that it can be investigated properly.
          Hide
          Nick Gault added a comment -

          Could someone please summarise the situation with this issue? Is there a fix in sight? At the moment I am steadily losing the good will of some of our most active Moodle evangelists, if I could offer an eta for a fix that would certainly help.

          Show
          Nick Gault added a comment - Could someone please summarise the situation with this issue? Is there a fix in sight? At the moment I am steadily losing the good will of some of our most active Moodle evangelists, if I could offer an eta for a fix that would certainly help.
          Hide
          Chris Meyer added a comment -

          Ditto that Nick. We're a pretty big install in North-West Wisconsin and it's killing us... Overall, we've been delighted with Moodle and have a lot of blood, sweat and tears invested in it.

          I'll bet it's some iterative coding practice that gets hung up. IE is usually more vulnerable to such things because it's not as open source friendly.

          Can the developers give us some idea of where in the code the problem seems to be. I'd be willing to do some testing with timed loops to see if anything turns up. Also, my previous link to the 10 most frequent slowdowns and other such Internet gems may hold some practical clues for such testing.

          • Chris Meyer: CESA 10
          Show
          Chris Meyer added a comment - Ditto that Nick. We're a pretty big install in North-West Wisconsin and it's killing us... Overall, we've been delighted with Moodle and have a lot of blood, sweat and tears invested in it. I'll bet it's some iterative coding practice that gets hung up. IE is usually more vulnerable to such things because it's not as open source friendly. Can the developers give us some idea of where in the code the problem seems to be. I'd be willing to do some testing with timed loops to see if anything turns up. Also, my previous link to the 10 most frequent slowdowns and other such Internet gems may hold some practical clues for such testing. Chris Meyer: CESA 10
          Hide
          Andrew Nicols added a comment -

          Nick, Chris:

          As I commented a few comments above, we've already committed one patchset which should make a big difference - thanks to Paul Nicholls for those. We're also still looking to address other areas which are particularly problematic.

          There are six commits so far addressing some javascript performance issues - you can see them here: https://github.com/moodle/moodle/commits/master?page=2.

          If you're aware of any specific areas in the JS affecting your installation, then it would be useful to know exactly what. I've been working on a rewrite of the dropdown box code, but this is pretty tricky to get right. I believe that the module chooser code could be optimised a little and I've been testing a patch with this, but the biggest area seems to be the navigation tree which I'm not familiar with at all.

          Any help would be much appreciated,

          Andrew

          Show
          Andrew Nicols added a comment - Nick, Chris: As I commented a few comments above, we've already committed one patchset which should make a big difference - thanks to Paul Nicholls for those. We're also still looking to address other areas which are particularly problematic. There are six commits so far addressing some javascript performance issues - you can see them here: https://github.com/moodle/moodle/commits/master?page=2 . If you're aware of any specific areas in the JS affecting your installation, then it would be useful to know exactly what. I've been working on a rewrite of the dropdown box code, but this is pretty tricky to get right. I believe that the module chooser code could be optimised a little and I've been testing a patch with this, but the biggest area seems to be the navigation tree which I'm not familiar with at all. Any help would be much appreciated, Andrew
          Hide
          Chris Meyer added a comment -

          Thanks for the update Andrew. I'll bring my test server up to date, test our biggest problem areas and see if I can get any useful info for you guys. Thanks for all your work. Chris

          Show
          Chris Meyer added a comment - Thanks for the update Andrew. I'll bring my test server up to date, test our biggest problem areas and see if I can get any useful info for you guys. Thanks for all your work. Chris
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Note that some problems have been found, potentially related with the code introduced last week while testing http://tracker.moodle.org/browse/MDL-35616?focusedCommentId=181541&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-181541 !

          So MDL-35767 has been created as a regression of this.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Note that some problems have been found, potentially related with the code introduced last week while testing http://tracker.moodle.org/browse/MDL-35616?focusedCommentId=181541&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-181541 ! So MDL-35767 has been created as a regression of this. Ciao
          Hide
          Dan Poltawski added a comment -

          Given the regression spotted above, it seems like this shouldn't have landed in the stable branch. If we're not able to get a resolution to that issue before the weekly release tomorrow, then i'm afraid we'll be looking at reverting these changes to arrive at a slightly more stable stable branch.

          Show
          Dan Poltawski added a comment - Given the regression spotted above, it seems like this shouldn't have landed in the stable branch. If we're not able to get a resolution to that issue before the weekly release tomorrow, then i'm afraid we'll be looking at reverting these changes to arrive at a slightly more stable stable branch.
          Hide
          Tom Butkiewicz added a comment -

          My users have been reporting not being able to drag and drop on the course view. Our production site is running MOODLE_23_STABLE (Moodle 2.3.2+).

          When you hover over the move icon on an item in the course view, you will get the 4-way arrow mouse icon - as intended.

          Then when you go to move, it will change to a circle with a slash through it as it is trying to actually move the "move_2d.gif" image on the page - which it cannot.

          After looking into the issue, I was able to reproduce the problem and this is what I found:

          1. Reproduced on MOODLE_23_STABLE, MOODLE_232, MOODLE_231
          2. It only affects users running the latest version of Google Chrome version 22.0.1229.79 m
          3. It affects versions of Moodle 2.3.X
            • Moodle 2.2.X drag and drop works as intended
          4. All other in-line functions work - Edit title, Move right, Update, duplicate, etc
          5. No errors are reported from the browser or server (js, php, apache, etc)
          6. Most importantly - On a computer that drag and drop is working, I notice an additional id=yui_3_5_1_etc_etc_etc whereas on computers that are affected do not have any id=attribute at all on the item trying to be moved.
          7. AJAX is turned on, tried with online YUI enabled/disabled, tried YUI combo loading enabled/disabled, tried cache jS enabled/disabled.
          8. Deleted browser cache after toggling each AJAX setting.
          9. All other navigation menus work as intended. Drag and dropping a file directly onto the course works as well.

          I've been trying to narrow this issue down on my own and find a fix before submitting but I have not been able to do so.

          I believe this is related to the drag drop issues being talked about here, if it is not I apologize and will make a new report!

          Thanks for your help and input,
          -Tom

          Show
          Tom Butkiewicz added a comment - My users have been reporting not being able to drag and drop on the course view. Our production site is running MOODLE_23_STABLE (Moodle 2.3.2+). When you hover over the move icon on an item in the course view, you will get the 4-way arrow mouse icon - as intended. Then when you go to move, it will change to a circle with a slash through it as it is trying to actually move the "move_2d.gif" image on the page - which it cannot. After looking into the issue, I was able to reproduce the problem and this is what I found: Reproduced on MOODLE_23_STABLE, MOODLE_232, MOODLE_231 It only affects users running the latest version of Google Chrome version 22.0.1229.79 m It affects versions of Moodle 2.3.X Moodle 2.2.X drag and drop works as intended All other in-line functions work - Edit title, Move right, Update, duplicate, etc No errors are reported from the browser or server (js, php, apache, etc) Most importantly - On a computer that drag and drop is working, I notice an additional id=yui_3_5_1_etc_etc_etc whereas on computers that are affected do not have any id=attribute at all on the item trying to be moved. AJAX is turned on, tried with online YUI enabled/disabled, tried YUI combo loading enabled/disabled, tried cache jS enabled/disabled. Deleted browser cache after toggling each AJAX setting. All other navigation menus work as intended. Drag and dropping a file directly onto the course works as well. I've been trying to narrow this issue down on my own and find a fix before submitting but I have not been able to do so. I believe this is related to the drag drop issues being talked about here, if it is not I apologize and will make a new report! Thanks for your help and input, -Tom
          Hide
          Nick Gault added a comment -

          I have tested some of the affected courses using ie9 and they appear to be working perfectly.

          Show
          Nick Gault added a comment - I have tested some of the affected courses using ie9 and they appear to be working perfectly.
          Hide
          Andrew Nicols added a comment -

          Hi Nick,

          Were you seeing these issues before these patches were applied?

          Cheers,

          Andrew

          Show
          Andrew Nicols added a comment - Hi Nick, Were you seeing these issues before these patches were applied? Cheers, Andrew
          Hide
          Nick Gault added a comment -

          Hi Andrew,

          No patches applied, our IT department installed some machines with ie9 to see if this would help the users and it has made a noticeable improvement.

          Build: 20120910

          If there is any other info that may help just let me know.

          Cheers,

          Nick

          Show
          Nick Gault added a comment - Hi Andrew, No patches applied, our IT department installed some machines with ie9 to see if this would help the users and it has made a noticeable improvement. Build: 20120910 If there is any other info that may help just let me know. Cheers, Nick
          Hide
          Jeff Green added a comment -

          I am havnig this unresponsive issue for large courses. Is there a fix in sight for this? I've read through this entire topic and tried the patches proposed and am still having the error. I've turned off everything under JAVA/AJAX settings and am still having the problem. The course opens OK but does take a little longer than other courses. When Turn Editing On is clicked, it freezes. I can't even get my profiler data after I click turn editing on. I'm currently running the most current 2.3.3+ build. Thanks in advance!

          Show
          Jeff Green added a comment - I am havnig this unresponsive issue for large courses. Is there a fix in sight for this? I've read through this entire topic and tried the patches proposed and am still having the error. I've turned off everything under JAVA/AJAX settings and am still having the problem. The course opens OK but does take a little longer than other courses. When Turn Editing On is clicked, it freezes. I can't even get my profiler data after I click turn editing on. I'm currently running the most current 2.3.3+ build. Thanks in advance!
          Hide
          Paul Nicholls added a comment -

          Hi Jeff,
          The patches here are just a start - and they'll hopefully make a small improvement, but if you have really large courses, that improvement may not be enough to make them usable. Personally, I've been on vacation for the past month; I'm heading home this evening, and when I'm back at work (in a few days' time), this issue will still be very high on my list - once I've cleared the backlog of things that've piled up while I've been away, I'll be right back into working on this issue.

          The biggest hurdle to dealing with this issue is data - figuring out what's actually causing the performance issues. If you're able to give me access to some courses which are having this issue, that would be incredibly helpful - it seems that it's not really one issue, but rather a multitude of smaller issues all working together to cause big performance issues, so the more data we can gather, the better. If you're able to provide course backups (without users or user data) for a few troublesome courses, that'd be incredibly helpful, as it'd allow me - and perhaps other developers such as Andrew, their time willing - to test changes against your troublesome courses on our own development sites.

          -Paul

          Show
          Paul Nicholls added a comment - Hi Jeff, The patches here are just a start - and they'll hopefully make a small improvement, but if you have really large courses, that improvement may not be enough to make them usable. Personally, I've been on vacation for the past month; I'm heading home this evening, and when I'm back at work (in a few days' time), this issue will still be very high on my list - once I've cleared the backlog of things that've piled up while I've been away, I'll be right back into working on this issue. The biggest hurdle to dealing with this issue is data - figuring out what's actually causing the performance issues. If you're able to give me access to some courses which are having this issue, that would be incredibly helpful - it seems that it's not really one issue, but rather a multitude of smaller issues all working together to cause big performance issues, so the more data we can gather, the better. If you're able to provide course backups (without users or user data) for a few troublesome courses, that'd be incredibly helpful, as it'd allow me - and perhaps other developers such as Andrew, their time willing - to test changes against your troublesome courses on our own development sites. -Paul
          Hide
          Eloy Lafuente (stronk7) added a comment -

          U P S T R E A M I Z E D !

          Many thanks, this is now available in all the repos (git & cvs).

          Closing, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - U P S T R E A M I Z E D ! Many thanks, this is now available in all the repos (git & cvs). Closing, ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Doh,

          somehow this issue was closed incorrectly when processing all the integrated issues this week. (sort of most voted and current in integration filters mix). Apologies for the confusion, reseting to previous status!

          Ciao, Eloy

          Show
          Eloy Lafuente (stronk7) added a comment - Doh, somehow this issue was closed incorrectly when processing all the integrated issues this week. (sort of most voted and current in integration filters mix). Apologies for the confusion, reseting to previous status! Ciao, Eloy
          Hide
          Chris Meyer added a comment -

          Hi,

          What seems to be choking our larger courses is all the javascript at the bottom of the page. One course's rendered page has 600 lines starting with "Y.on('click'" at the end. IE just can't hack it. To test things out a bit, I altered the rendering in outputrequirementslib.php to drop all the $handlersjs code (the Y.on('click' stuff) and ripped out any lines in $jsinit beginning with "M.util" with the following code: $jsinit = preg_replace("/M\.util\..+?\n/","",$jsinit);

          Now Moodle doesn't fail, though especially under IE some courses remain painfully sluggish. (If size could be an issue, recommendations for max sections, etc. are welcome.)

          Two questions. 1) Am I missing much by removing that code? (We are running this altered code only on our test server) 2) If that code is needed, could it be loaded after the DOM is loaded (ondomreadyjs) by using XMLHttpRequests to send the data needed to have javascript provide the tweaks to the affected DOM objects? I think especially IE might tolerate this better as courses get larger and the code size only continues to grow.

          Chris Meyer, CESA 10 Systems Administrator

          Show
          Chris Meyer added a comment - Hi, What seems to be choking our larger courses is all the javascript at the bottom of the page. One course's rendered page has 600 lines starting with "Y.on('click'" at the end. IE just can't hack it. To test things out a bit, I altered the rendering in outputrequirementslib.php to drop all the $handlersjs code (the Y.on('click' stuff) and ripped out any lines in $jsinit beginning with "M.util" with the following code: $jsinit = preg_replace("/M\.util\..+?\n/","",$jsinit); Now Moodle doesn't fail, though especially under IE some courses remain painfully sluggish. (If size could be an issue, recommendations for max sections, etc. are welcome.) Two questions. 1) Am I missing much by removing that code? (We are running this altered code only on our test server) 2) If that code is needed, could it be loaded after the DOM is loaded (ondomreadyjs) by using XMLHttpRequests to send the data needed to have javascript provide the tweaks to the affected DOM objects? I think especially IE might tolerate this better as courses get larger and the code size only continues to grow. Chris Meyer, CESA 10 Systems Administrator
          Hide
          Chris Meyer added a comment -

          By the way guys. I volunteer CESA 10 to help on this. We have some large courses with problems. I can send copies of the rendered pages (one with edit off, and the other with edit on). The edit on version is 4 times as big as the edit off. Let me know if I can help.

          Chris

          Show
          Chris Meyer added a comment - By the way guys. I volunteer CESA 10 to help on this. We have some large courses with problems. I can send copies of the rendered pages (one with edit off, and the other with edit on). The edit on version is 4 times as big as the edit off. Let me know if I can help. Chris
          Hide
          Jeff Green added a comment -

          Paul, my moodle site is available on the web. I'd be happy to make you a student or a teacher for this particular course if you want to take a look. It's a very large course. Just let me know! Thanks everyone for all your help on this. I can't revert back to 2.2.3 because of the changes that have already been made so I'm stuck.

          Show
          Jeff Green added a comment - Paul, my moodle site is available on the web. I'd be happy to make you a student or a teacher for this particular course if you want to take a look. It's a very large course. Just let me know! Thanks everyone for all your help on this. I can't revert back to 2.2.3 because of the changes that have already been made so I'm stuck.
          Hide
          Vicki Dunnam added a comment -

          I will be glad to test if needed. We are still having issues and we can't revert back either. Anything you need from us to help in troubleshooting... please let me know.

          Show
          Vicki Dunnam added a comment - I will be glad to test if needed. We are still having issues and we can't revert back either. Anything you need from us to help in troubleshooting... please let me know.
          Hide
          Andrew Nicols added a comment -

          Hi Jeff,

          That's really helpful information. Is there any chance you could attach a fully rendered course page (HTML) complete with the stuff you've stripped out. That would be really helfpul - the features course on qa.moodle.net doesn't seem to have many Y.on events (http://qa.moodle.net/course/view.php?id=2&notifyeditingon=1) and I haven't got another Moodle to play with this minute.

          Cheers,

          Andrew

          Show
          Andrew Nicols added a comment - Hi Jeff, That's really helpful information. Is there any chance you could attach a fully rendered course page (HTML) complete with the stuff you've stripped out. That would be really helfpul - the features course on qa.moodle.net doesn't seem to have many Y.on events ( http://qa.moodle.net/course/view.php?id=2&notifyeditingon=1 ) and I haven't got another Moodle to play with this minute. Cheers, Andrew
          Hide
          Jeff Green added a comment -

          For what it's worth, I've completely removed Java from my PC and it still kills IE. Not sure if that's good news or bad news haha. I'd be happy to post a page but can't get IE to do a thing once I've turned editing on. Would you like a page BEFORE editnig is turned on?

          Show
          Jeff Green added a comment - For what it's worth, I've completely removed Java from my PC and it still kills IE. Not sure if that's good news or bad news haha. I'd be happy to post a page but can't get IE to do a thing once I've turned editing on. Would you like a page BEFORE editnig is turned on?
          Hide
          Jeff Green added a comment - - edited

          Here is a large course saved page before editing is turned on. It's the Course Parris yadda yadda at the top. Please let me know if that's not what you need and I'll do what I can to get it to ya.

          If any programmer helping on this problem needs access to a large course, please let me know.

          Show
          Jeff Green added a comment - - edited Here is a large course saved page before editing is turned on. It's the Course Parris yadda yadda at the top. Please let me know if that's not what you need and I'll do what I can to get it to ya. If any programmer helping on this problem needs access to a large course, please let me know.
          Hide
          Andrew Nicols added a comment -

          I've had a look at some bits already - in summary:

          I think we can do some work to really improve the efficiency of M.util.help_icon.add() - again it uses an onclick event so there's one per helpicon, and there's one help icon per dropdown. I've added MDL-35819 to address it. Anywhere there are help icons (large forms) will also suffer this.

          I've already raised another issue for the number of init_select_autosubmit calls (MDL-35569) which I suspect are also likely to be massively inefficient.

          Show
          Andrew Nicols added a comment - I've had a look at some bits already - in summary: I think we can do some work to really improve the efficiency of M.util.help_icon.add() - again it uses an onclick event so there's one per helpicon, and there's one help icon per dropdown. I've added MDL-35819 to address it. Anywhere there are help icons (large forms) will also suffer this. I've already raised another issue for the number of init_select_autosubmit calls ( MDL-35569 ) which I suspect are also likely to be massively inefficient.
          Hide
          Andrew Nicols added a comment -

          If you disable Javascript in your browser, then you should be able to turn editing on. If you can give me access to the course, that'd be great. Java and JavaScript aren't the same thing I'm afraid. I'm not exactly sure how you turn off JS - It's somewhere in Tools -> Options. Choose Security Level and I think you have to use a Custom Level. It's called 'Scripting' fI think.

          Show
          Andrew Nicols added a comment - If you disable Javascript in your browser, then you should be able to turn editing on. If you can give me access to the course, that'd be great. Java and JavaScript aren't the same thing I'm afraid. I'm not exactly sure how you turn off JS - It's somewhere in Tools -> Options. Choose Security Level and I think you have to use a Custom Level. It's called 'Scripting' fI think.
          Hide
          Chris Meyer added a comment -

          OK Andrew,

          I've got two files on our website for download:
          http://www.cesa10.k12.wi.us/pickup/viewediton.txt and
          http://www.cesa10.k12.wi.us/pickup/vieweditonlessjs.txt

          Viewediton.txt has all the javascript and vieweditonlessjs.txt has the same page with the javascript stripped out as I described above. Hope this helps.

          Viewediton dies - Vieweditonlessjs survives...

          Make sure and use a full path to the files since there is a bogus index.php in that dir. I included some comment lines with my name to make places where stuff starts and stops for reference.

          Good luck.

          If this is helpful we can do more of this.

          Chris

          Show
          Chris Meyer added a comment - OK Andrew, I've got two files on our website for download: http://www.cesa10.k12.wi.us/pickup/viewediton.txt and http://www.cesa10.k12.wi.us/pickup/vieweditonlessjs.txt Viewediton.txt has all the javascript and vieweditonlessjs.txt has the same page with the javascript stripped out as I described above. Hope this helps. Viewediton dies - Vieweditonlessjs survives... Make sure and use a full path to the files since there is a bogus index.php in that dir. I included some comment lines with my name to make places where stuff starts and stops for reference. Good luck. If this is helpful we can do more of this. Chris
          Hide
          Andrew Nicols added a comment -

          Hi Chris,

          Looking at the output you've given that's a great help. One thing which others have pointed at above is the use of the doctonewwindow setting. Having this enabled is what's generating all of these onclick events. You'll find that unsetting this will really help your performance in the mean time.

          I'll add another subtask to the other bug so we can get this particular issue addressed too.

          Andrew

          Show
          Andrew Nicols added a comment - Hi Chris, Looking at the output you've given that's a great help. One thing which others have pointed at above is the use of the doctonewwindow setting. Having this enabled is what's generating all of these onclick events. You'll find that unsetting this will really help your performance in the mean time. I'll add another subtask to the other bug so we can get this particular issue addressed too. Andrew
          Hide
          Nick Gault added a comment -

          Just discovered that the backup process hangs when trying to back these large courses up.

          If anyone can suggest a way to troubleshoot this I will post the results here.

          Show
          Nick Gault added a comment - Just discovered that the backup process hangs when trying to back these large courses up. If anyone can suggest a way to troubleshoot this I will post the results here.
          Hide
          John Holmes added a comment -

          Nick, we had similar issues and found that changing max post from 1000 to 5000 in php.ini as described here: http://moodle.org/mod/forum/discuss.php?d=190110&parent=880671
          solved our problem.
          This allowed me to backup my course to provide to MoodleHQ for purposes of troubleshooting

          Show
          John Holmes added a comment - Nick, we had similar issues and found that changing max post from 1000 to 5000 in php.ini as described here: http://moodle.org/mod/forum/discuss.php?d=190110&parent=880671 solved our problem. This allowed me to backup my course to provide to MoodleHQ for purposes of troubleshooting
          Hide
          Richard van Iwaarden added a comment - - edited

          I don't know if this is related, but there's a similar issue with the browser being extremely unresponsive.

          1. Backup a course with quite some content
          2. Go to step 2 (the step with all the content on the screen)
          3. Choose 'deselect all' and start selecting content to backup.

          You will now notice that the mark/unmark is extremely slow. Sometimes the checkmark will take more than 10 seconds to appear.

          I don't know whats the deal with this page, but browsers can't seem to be able to handle this. I checked it in IE and Chrome, same results.

          Show
          Richard van Iwaarden added a comment - - edited I don't know if this is related, but there's a similar issue with the browser being extremely unresponsive. 1. Backup a course with quite some content 2. Go to step 2 (the step with all the content on the screen) 3. Choose 'deselect all' and start selecting content to backup. You will now notice that the mark/unmark is extremely slow. Sometimes the checkmark will take more than 10 seconds to appear. I don't know whats the deal with this page, but browsers can't seem to be able to handle this. I checked it in IE and Chrome, same results.
          Hide
          Sambg added a comment -

          As we're on the topic, the file picker on these long courses is returning a script unresponsive dialogue here, particularly when trying to do anything with a lot of server files listed.

          Sam.

          Show
          Sambg added a comment - As we're on the topic, the file picker on these long courses is returning a script unresponsive dialogue here, particularly when trying to do anything with a lot of server files listed. Sam.
          Hide
          Koen Roggemans added a comment - - edited

          I think the backup related comments belong in MDL-35484

          Show
          Koen Roggemans added a comment - - edited I think the backup related comments belong in MDL-35484
          Hide
          Chris Meyer added a comment -

          Hi Andrew,

          Thanks for looking into this. I had the docstonewwindow turned off on our production server because I had seen a note about that on this page, however I seem to have missed it on the test box. I've turned it off and now only get 2 of the Y.on('Click'... lines. The M.util.init and M.util.help pairs found in $jsinit of outputrequirementslib.php are still enough to get IE to warn about the length of time the javascript is taking. If you've got a plan for that, I think we'd be set here. Any thoughts about running that stuff after the DOM is loaded by requesting any needed data from server with an XMLHttpRequest and then running some nice javascript loop to process it?

          We'll continue working on our large Course sizes - any Moodle best practices notes on this are most welcome.

          Let me know if there is anything else I can do to help you test. I'm available from 7:30 - 4:00 CST US, Mon-Fri.

          Regards Chris

          Show
          Chris Meyer added a comment - Hi Andrew, Thanks for looking into this. I had the docstonewwindow turned off on our production server because I had seen a note about that on this page, however I seem to have missed it on the test box. I've turned it off and now only get 2 of the Y.on('Click'... lines. The M.util.init and M.util.help pairs found in $jsinit of outputrequirementslib.php are still enough to get IE to warn about the length of time the javascript is taking. If you've got a plan for that, I think we'd be set here. Any thoughts about running that stuff after the DOM is loaded by requesting any needed data from server with an XMLHttpRequest and then running some nice javascript loop to process it? We'll continue working on our large Course sizes - any Moodle best practices notes on this are most welcome. Let me know if there is anything else I can do to help you test. I'm available from 7:30 - 4:00 CST US, Mon-Fri. Regards Chris
          Hide
          Andrew Nicols added a comment -

          Hi Chris,

          I've put a patch for M.util.init_url_select into MDL-35569 - haven't had a chance to finish testing it, but if you fancy trialling that patch it would be interesting to know how that helps.
          I started looking at M.util.help_icon.add last night but didn't get a chance to get anything concrete together.

          I don't htink that using XML requests is the way forward - they'd be quite intensive and we don't currently have a way of storing page state between page loads to know for certain which JS components to return; plus most of those which would be affected have IDs generated on the fly so no two page loads would necessarily be the same. We can do this much better and much more simply by using event delegation. Should also shave a bit off page generation time and generated page size.

          Cheers,

          Andrew

          Show
          Andrew Nicols added a comment - Hi Chris, I've put a patch for M.util.init_url_select into MDL-35569 - haven't had a chance to finish testing it, but if you fancy trialling that patch it would be interesting to know how that helps. I started looking at M.util.help_icon.add last night but didn't get a chance to get anything concrete together. I don't htink that using XML requests is the way forward - they'd be quite intensive and we don't currently have a way of storing page state between page loads to know for certain which JS components to return; plus most of those which would be affected have IDs generated on the fly so no two page loads would necessarily be the same. We can do this much better and much more simply by using event delegation. Should also shave a bit off page generation time and generated page size. Cheers, Andrew
          Hide
          Vicki Dunnam added a comment -

          We are definitely having problems with the unresponsive browser when trying to edit quiz settings to hide/show. Or any activity for that matters.
          We are using 2.3.2+ Build 20120927). We are waiting to upload this latest one today at 5.

          I have some large courses and would be happy to send them to you to review if that would help in trying to resolve this issue.

          Reading through the comments... where do you turn off "Show all courses"? I have looked at the front page settings and those are set to None.

          We are so glad you are working on resolving this issue because it is really hard to manage courses when it will not save settings and just continues the loop. Any way I can help,please let me know.

          Show
          Vicki Dunnam added a comment - We are definitely having problems with the unresponsive browser when trying to edit quiz settings to hide/show. Or any activity for that matters. We are using 2.3.2+ Build 20120927). We are waiting to upload this latest one today at 5. I have some large courses and would be happy to send them to you to review if that would help in trying to resolve this issue. Reading through the comments... where do you turn off "Show all courses"? I have looked at the front page settings and those are set to None. We are so glad you are working on resolving this issue because it is really hard to manage courses when it will not save settings and just continues the loop. Any way I can help,please let me know.
          Hide
          Vicki Dunnam added a comment -

          Since we are unable to change a quiz from "hidden" to "show" because of unresponsive browser. Can someone direct me on how I can use phpmyadmin to change it in the table? I looked in the mdl_quiz table but there are not fields that indicate the visible portion of the quiz that is listed under the common module settings in the quiz. That might be a work around for getting these quizzes set up in Moodle. Any help is so appreciated.

          Show
          Vicki Dunnam added a comment - Since we are unable to change a quiz from "hidden" to "show" because of unresponsive browser. Can someone direct me on how I can use phpmyadmin to change it in the table? I looked in the mdl_quiz table but there are not fields that indicate the visible portion of the quiz that is listed under the common module settings in the quiz. That might be a work around for getting these quizzes set up in Moodle. Any help is so appreciated.
          Hide
          Koen Roggemans added a comment -

          Since the fix seems quite difficult, would it be possible to reverting MDL-32509

          Show
          Koen Roggemans added a comment - Since the fix seems quite difficult, would it be possible to reverting MDL-32509
          Hide
          Paul Nicholls added a comment -

          Nick, to clarify what John said, you may need to increase the PHP setting max_input_vars (default is 1000, as John said) in order to make the manual backup process work for large courses; that's something different from the ticket Koen linked to, but probably ought to be reported (if it hasn't been already). It's actually something else that's on my list of things to do - some changes to the structure of the form should remove the need to adjust max_input_vars - but there's only one of me! Automatic (scheduled) backups should still run fine without needing to adjust max_input_vars.

          Koen, reverting MDL-32509 wouldn't help - all that change did was remove the option to enable/disable AJAX at the course level. If you're having issues with large courses, you'd probably be better off just disabling it at the site level - but even disabling AJAX may not alleviate the performance issues, as there's plenty of JavaScript which still runs with AJAX disabled.

          Show
          Paul Nicholls added a comment - Nick, to clarify what John said, you may need to increase the PHP setting max_input_vars (default is 1000, as John said) in order to make the manual backup process work for large courses; that's something different from the ticket Koen linked to, but probably ought to be reported (if it hasn't been already). It's actually something else that's on my list of things to do - some changes to the structure of the form should remove the need to adjust max_input_vars - but there's only one of me! Automatic (scheduled) backups should still run fine without needing to adjust max_input_vars. Koen, reverting MDL-32509 wouldn't help - all that change did was remove the option to enable/disable AJAX at the course level. If you're having issues with large courses, you'd probably be better off just disabling it at the site level - but even disabling AJAX may not alleviate the performance issues, as there's plenty of JavaScript which still runs with AJAX disabled.
          Hide
          Chris Meyer added a comment -

          Hi Andrew,

          Yeah, I'd be happy to test patches. Just let me know where they are and what to do to apply them.

          Chris

          Show
          Chris Meyer added a comment - Hi Andrew, Yeah, I'd be happy to test patches. Just let me know where they are and what to do to apply them. Chris
          Hide
          Martin Dougiamas added a comment -

          Bumping priority on this

          Show
          Martin Dougiamas added a comment - Bumping priority on this
          Hide
          Martin Dougiamas added a comment -

          Can someone summarise the current findings here? Andrew?

          What browsers does it affect?

          Are there solutions around that are not yet integrated?

          Show
          Martin Dougiamas added a comment - Can someone summarise the current findings here? Andrew? What browsers does it affect? Are there solutions around that are not yet integrated?
          Hide
          Andrew Nicols added a comment -

          Martin,

          All browsers are affected to some extent, but computers with less power are worst affected and IE is (surprise surprise) the worst under any circumstances. Users have generally reported that IE <=8 is worst affected and that upgrading to IE 9 really improves things for them. Switching to Firefox or Chrome also seems to help many as these are also less affected. It seems that they just have better JS handling.

          A chunk of work has already been committed in this issue to improve performance of the newer JS introduced in Moodle 2.3, specifically on Toolboxes, Module Chooser, and Drag/Drop (courtesy of Paul Nicholls). These weren't as much as of an issue IMO as the other issues I've been looking at but I suspect that they were the straw that broke the camel's back.

          I've been working on a stack of remaining JS performance issues as subtasks of MDL-35672. Im summary:

          Issues with a fix committed:

          • a change to improve efficiency of the formchangechecker has been committed. This really only affected larger forms - thanks to Tim Hunt for identifying it

          Issues without any work done yet:

          • an issue with the disabledif in form.js which the OU report as having a particularly bad affect on performance of the backup page

          The remaining three sub-issues are waiting for peer review (hint hint):

          • MDL-35569: the drop-down menus which automatically submit (e.g. add a block dropdown) are pretty inefficient. Courses with lots of sections will be affected as there's a pair of these per section (add a resource, add an activity).
          • MDL-35836: the doctonewwindow is horrifically bad on performance. I've rewritten the way it works to be better. This really will help, especially on IE8 and before, but on all browsers really. It could probably do with being rewritten as a YUI module but this requires a bit more thought and is a good candidate for 2.5.
          • MDL-35819: the help tooltip popup is also pretty inefficient. I've completely rewritten that - it should also really help on larger courses since there are popup helps beside every dropdown activity/resource

          As an aside, with the above three issues applied together, they really reduce the size of a generated page (200KB on a 1.3MB page from a large course). They also reduce the number of PHP calls massively too which should help PHP performance.

          Most of the issues I've addressed have been related to multiple uses of on('click') rather than delegated clicks; multiple uses of Y.one(); and checking of properties at page load times. These have primarily been addressed in such a way that we add a class to the item being worked on, delegate once for all of them, and then work out what to do if and when they're pressed.

          I don't know if I'll have time to work on any more of these before freeze now so if someone from HQ or elsewhere can help identify or work on any of the other issues that'd be great. The forms.js one the OU identified is a key candidate though.

          I think that we should look at adding some more JS guidelines to the developer docs, and pay more attention to them at review and integration time in the future.

          Cheers,

          Andrew

          Show
          Andrew Nicols added a comment - Martin, All browsers are affected to some extent, but computers with less power are worst affected and IE is (surprise surprise) the worst under any circumstances. Users have generally reported that IE <=8 is worst affected and that upgrading to IE 9 really improves things for them. Switching to Firefox or Chrome also seems to help many as these are also less affected. It seems that they just have better JS handling. A chunk of work has already been committed in this issue to improve performance of the newer JS introduced in Moodle 2.3, specifically on Toolboxes, Module Chooser, and Drag/Drop (courtesy of Paul Nicholls). These weren't as much as of an issue IMO as the other issues I've been looking at but I suspect that they were the straw that broke the camel's back. I've been working on a stack of remaining JS performance issues as subtasks of MDL-35672 . Im summary: Issues with a fix committed: a change to improve efficiency of the formchangechecker has been committed. This really only affected larger forms - thanks to Tim Hunt for identifying it Issues without any work done yet: an issue with the disabledif in form.js which the OU report as having a particularly bad affect on performance of the backup page The remaining three sub-issues are waiting for peer review (hint hint): MDL-35569 : the drop-down menus which automatically submit (e.g. add a block dropdown) are pretty inefficient. Courses with lots of sections will be affected as there's a pair of these per section (add a resource, add an activity). MDL-35836 : the doctonewwindow is horrifically bad on performance. I've rewritten the way it works to be better. This really will help, especially on IE8 and before, but on all browsers really. It could probably do with being rewritten as a YUI module but this requires a bit more thought and is a good candidate for 2.5. MDL-35819 : the help tooltip popup is also pretty inefficient. I've completely rewritten that - it should also really help on larger courses since there are popup helps beside every dropdown activity/resource As an aside, with the above three issues applied together, they really reduce the size of a generated page (200KB on a 1.3MB page from a large course). They also reduce the number of PHP calls massively too which should help PHP performance. Most of the issues I've addressed have been related to multiple uses of on('click') rather than delegated clicks; multiple uses of Y.one(); and checking of properties at page load times. These have primarily been addressed in such a way that we add a class to the item being worked on, delegate once for all of them, and then work out what to do if and when they're pressed. I don't know if I'll have time to work on any more of these before freeze now so if someone from HQ or elsewhere can help identify or work on any of the other issues that'd be great. The forms.js one the OU identified is a key candidate though. I think that we should look at adding some more JS guidelines to the developer docs, and pay more attention to them at review and integration time in the future. Cheers, Andrew
          Hide
          Jeff Green added a comment -

          Just wanted to throw out I'm having the same extreme slow/hanging result whether I use IE8, IE9 or FireFox.

          Show
          Jeff Green added a comment - Just wanted to throw out I'm having the same extreme slow/hanging result whether I use IE8, IE9 or FireFox.
          Hide
          Brett Graham added a comment -

          I wonder if this issue hasn't become a gathering point for many disparate performance issues in various versions of Moodle.

          The title of this issue describes our experience perfectly... "Browser Unresponsive when editing turned on for large courses Moodle 2.3+"

          ie. We have only experienced this in Moodle v2.3. To narrow down to perhaps a single issue, it is mainly with IE9 when turning editing on for courses with a large number of sections. (As distinct from a large number of links or activities.)

          When this issue was first reported back in July, the first few comments described the situation perfectly. Since then, however, the thread perhaps has traversed a different track.

          See comments from...

          1. Michael de Raadt - 16 July 2012
          "The problem seems to be across browsers, but is more noticeable in IE. I noticed the same results in FF and Chrome. The page load times are not affected. It is a script that runs after the page is loaded. With a large number of activities/sections the browser continuously consumes a large amount of CPU while seeing to do nothing. The activity chooser is loaded and the drag-and-drop controls are loaded, but the browser continues to run some script in the background."

          ... and ...

          2. Virgil Ashruf - 20 July 2012
          "I can reproduce this problem as well. I have upgraded a large environment from 2.2.3+ to 2.3.1. Teachers who are using the summer holiday to update their courses are experiencing a lot of trouble completing their work. In IE9 the browser completely freezes. In IE8 the browser complete shuts down. Chrome kills the page and Firefox becomes less responsive."

          ... and ...

          3. Michael Woods - 26 July 2012
          "What I've found is that it's almost purely a factor of the number of SECTIONS in a course, not really the number of resources/activities. Eg. Load time for a course with 20 BLANK sections is almost not usable in edit mode, but a course with 1 section containing 100 resources is fine."

          To summarise...

          • To me the problem only emerged with v2.3.
          • It is most pronounced with Internet Explorer.
          • It is to do when turning editing on and the long wait before the page is loaded and editable.
          • It is to do with the number of course sections not activities/resources. In fact you could have 20+ empty sections and experience the problem.

          I'm not suggesting that there aren't other issues with other versions or quizzes or activities, however I wonder if focussing on this one 'turn editing on' issue might be worthwhile.

          I remain grateful to all of you who are putting time and energy into investigating the issue. If I am off track or missed something, please disregard.

          Regards
          Brett

          Show
          Brett Graham added a comment - I wonder if this issue hasn't become a gathering point for many disparate performance issues in various versions of Moodle. The title of this issue describes our experience perfectly... "Browser Unresponsive when editing turned on for large courses Moodle 2.3+" ie. We have only experienced this in Moodle v2.3. To narrow down to perhaps a single issue, it is mainly with IE9 when turning editing on for courses with a large number of sections. (As distinct from a large number of links or activities.) When this issue was first reported back in July, the first few comments described the situation perfectly. Since then, however, the thread perhaps has traversed a different track. See comments from... 1. Michael de Raadt - 16 July 2012 "The problem seems to be across browsers, but is more noticeable in IE. I noticed the same results in FF and Chrome. The page load times are not affected. It is a script that runs after the page is loaded. With a large number of activities/sections the browser continuously consumes a large amount of CPU while seeing to do nothing. The activity chooser is loaded and the drag-and-drop controls are loaded, but the browser continues to run some script in the background." ... and ... 2. Virgil Ashruf - 20 July 2012 "I can reproduce this problem as well. I have upgraded a large environment from 2.2.3+ to 2.3.1. Teachers who are using the summer holiday to update their courses are experiencing a lot of trouble completing their work. In IE9 the browser completely freezes. In IE8 the browser complete shuts down. Chrome kills the page and Firefox becomes less responsive." ... and ... 3. Michael Woods - 26 July 2012 "What I've found is that it's almost purely a factor of the number of SECTIONS in a course, not really the number of resources/activities. Eg. Load time for a course with 20 BLANK sections is almost not usable in edit mode, but a course with 1 section containing 100 resources is fine." To summarise... To me the problem only emerged with v2.3. It is most pronounced with Internet Explorer. It is to do when turning editing on and the long wait before the page is loaded and editable. It is to do with the number of course sections not activities/resources. In fact you could have 20+ empty sections and experience the problem. I'm not suggesting that there aren't other issues with other versions or quizzes or activities, however I wonder if focussing on this one 'turn editing on' issue might be worthwhile. I remain grateful to all of you who are putting time and energy into investigating the issue. If I am off track or missed something, please disregard. Regards Brett
          Hide
          Richard van Iwaarden added a comment -

          You are on track Brett, but please don't see this as an IE issue only. Firefox doesn't perform a lot better. In our schools I've made it so that all my users have switched to Chrome, which seems to work best for us. But even in Chrome the delay is to big for teachers do work properly with editing on in Moodle. And switching to Chrome is not an easy task to do in a complex cluster of schools and users...

          Show
          Richard van Iwaarden added a comment - You are on track Brett, but please don't see this as an IE issue only. Firefox doesn't perform a lot better. In our schools I've made it so that all my users have switched to Chrome, which seems to work best for us. But even in Chrome the delay is to big for teachers do work properly with editing on in Moodle. And switching to Chrome is not an easy task to do in a complex cluster of schools and users...
          Hide
          Andrew Nicols added a comment -

          As I mentioned in my summary, this issue is worst in IE8, but all browsers are affected. Some users have reported improvements with upgrading to IE9 (one even upgraded to Win7 and found it better). The changes I've been making are intended to improve performance in all browsers.

          The problem I've been primarily investigating is that of editing course pages - two of the issues I mentioned yesterday were issues reported by others about forms in Moodle - I have also spent time looking at those and I thought it best to mention them.

          The issues I've been working on are all directly related to the number of sections:

          • each section has two drop-downs
          • each section has two helps which can have both a popup, and a new window popup applied

          I agree, the number of resources doesn't seem to be a problem, more the number of sections.

          Andrew

          Show
          Andrew Nicols added a comment - As I mentioned in my summary, this issue is worst in IE8, but all browsers are affected. Some users have reported improvements with upgrading to IE9 (one even upgraded to Win7 and found it better). The changes I've been making are intended to improve performance in all browsers. The problem I've been primarily investigating is that of editing course pages - two of the issues I mentioned yesterday were issues reported by others about forms in Moodle - I have also spent time looking at those and I thought it best to mention them. The issues I've been working on are all directly related to the number of sections: each section has two drop-downs each section has two helps which can have both a popup, and a new window popup applied I agree, the number of resources doesn't seem to be a problem, more the number of sections. Andrew
          Hide
          Richard van Iwaarden added a comment - - edited

          I can confirm what Andrew says. Upgrading to IE9 and Win7 gives better performance. (IE9 doesn't run on WinXP)

          WinXP and IE8 are worst effected. Upgrading to IE10 and Win8 gives way better performance on this matter.

          Show
          Richard van Iwaarden added a comment - - edited I can confirm what Andrew says. Upgrading to IE9 and Win7 gives better performance. (IE9 doesn't run on WinXP) WinXP and IE8 are worst effected. Upgrading to IE10 and Win8 gives way better performance on this matter.
          Hide
          Jeff Green added a comment -

          Is there a way to revert back to 2.2.3 file structure without having to restore a previous copy of the database? I'm not sure what changes were made to the DB between 2.2.3 and 2.3.2 upgrade.

          At this point, I'm instructing my heavy users to turn off javascript in IE if they need to make changes to things. It may look a little different and some things may not work as expected, but clicking "Turn editing in" takes about 5 seconds to render a year-long course as opposed to a hanging browser with javascript turned on.

          Show
          Jeff Green added a comment - Is there a way to revert back to 2.2.3 file structure without having to restore a previous copy of the database? I'm not sure what changes were made to the DB between 2.2.3 and 2.3.2 upgrade. At this point, I'm instructing my heavy users to turn off javascript in IE if they need to make changes to things. It may look a little different and some things may not work as expected, but clicking "Turn editing in" takes about 5 seconds to render a year-long course as opposed to a hanging browser with javascript turned on.
          Hide
          Brett Graham added a comment -

          Thanks for the replies Andrew and Richard.

          Yes you are correct that IE8 and XP are a major problem. And yes, if it wasn't that IE is disastrous to use, I might not be as ready to accept the relatively less painful performance of Chrome and Firefox.

          I guess I was trying to prompt the focus to be on the core problem which seemed to be increasingly obscured by other issues/suggestions mentioned. The focus may well have been there but it was hard to tell in the comment trail.

          Again, thanks for all the work!

          Regards
          Brett

          Show
          Brett Graham added a comment - Thanks for the replies Andrew and Richard. Yes you are correct that IE8 and XP are a major problem. And yes, if it wasn't that IE is disastrous to use, I might not be as ready to accept the relatively less painful performance of Chrome and Firefox. I guess I was trying to prompt the focus to be on the core problem which seemed to be increasingly obscured by other issues/suggestions mentioned. The focus may well have been there but it was hard to tell in the comment trail. Again, thanks for all the work! Regards Brett
          Hide
          Chris Meyer added a comment -

          Update from CESA 10 on testing of patches by Andrew Nicols.

          We are testing a large course with 33 sections. Load time is pretty snappy in normal mode on all browsers. Going into edit mode, the load times are:

          15 Seconds Mozilla, 25 IE8 and 15 IE9. We're no longer getting the annoying javascript warnings on IE8. This is done with Javascript ON.

          I like what I am seeing.

          Chris Meyer

          Show
          Chris Meyer added a comment - Update from CESA 10 on testing of patches by Andrew Nicols. We are testing a large course with 33 sections. Load time is pretty snappy in normal mode on all browsers. Going into edit mode, the load times are: 15 Seconds Mozilla, 25 IE8 and 15 IE9. We're no longer getting the annoying javascript warnings on IE8. This is done with Javascript ON. I like what I am seeing. Chris Meyer
          Hide
          Dan Poltawski added a comment -

          Hi Chris,

          Can you be specific what patches you are testing? In other issues?

          Show
          Dan Poltawski added a comment - Hi Chris, Can you be specific what patches you are testing? In other issues?
          Hide
          Chris Meyer added a comment -

          Andrew Nicols will know the details. We are just providing our test server to try out some patches because it has courses with lots of sections that load slowly and make editing difficult. We were seeing long load times, error warnings and lockups; especially with IE8. Whatever Andrew did, things are looking better.

          I hope the peer review process can move forward, and we can get the fixes into production soon.

          Chris

          Show
          Chris Meyer added a comment - Andrew Nicols will know the details. We are just providing our test server to try out some patches because it has courses with lots of sections that load slowly and make editing difficult. We were seeing long load times, error warnings and lockups; especially with IE8. Whatever Andrew did, things are looking better. I hope the peer review process can move forward, and we can get the fixes into production soon. Chris
          Hide
          Susan Mangan added a comment -

          I noticed above someone mentioned a problem with onclick() and that there was a potential patch for this? If there is anyway we can apply this manually while waiting for the next release, please let me know! Thanks!

          Reason being.... we have numerous sites that are being affected by the unresponsive browser issue.

          Right now, as a workaround, I'm trying to reduce our large section-ed courses to see if this helps get our instructors working again and in order to do this I am painstakingly moving items from one section to another.

          What I find odd is that even though I have reduced a 40 section course to 18, when I choose to import or backup it still shows all 40 sections. I went through each summary to make sure there was absolutely nothing in the HTML summary.Is this normal behavior for the course to retain all the sections even though they are not being used?

          So, with this new problem I thought I could try to import OR backup and restore only the 18 sections into a new shell but am having MAJOR issues with deselecting each individual section. A fix to the onclick() event seems as though it might help with this?

          Show
          Susan Mangan added a comment - I noticed above someone mentioned a problem with onclick() and that there was a potential patch for this? If there is anyway we can apply this manually while waiting for the next release, please let me know! Thanks! Reason being.... we have numerous sites that are being affected by the unresponsive browser issue. Right now, as a workaround, I'm trying to reduce our large section-ed courses to see if this helps get our instructors working again and in order to do this I am painstakingly moving items from one section to another. What I find odd is that even though I have reduced a 40 section course to 18, when I choose to import or backup it still shows all 40 sections. I went through each summary to make sure there was absolutely nothing in the HTML summary.Is this normal behavior for the course to retain all the sections even though they are not being used? So, with this new problem I thought I could try to import OR backup and restore only the 18 sections into a new shell but am having MAJOR issues with deselecting each individual section. A fix to the onclick() event seems as though it might help with this?
          Hide
          Chris Meyer added a comment -

          Feedback on 2.3.2+ Version 2012062502.09 20121018

          Tested with a large course of about 32 sections.

          IE8 load time with editing on: 75 seconds and must tell popup error message to continue Javascript.

          Other browsers load in about 15 seconds with no Javascript warning.

          Show
          Chris Meyer added a comment - Feedback on 2.3.2+ Version 2012062502.09 20121018 Tested with a large course of about 32 sections. IE8 load time with editing on: 75 seconds and must tell popup error message to continue Javascript. Other browsers load in about 15 seconds with no Javascript warning.
          Hide
          Andrew Nicols added a comment -

          Dan - I applied the fixes for help popups, doctonewwindow, and init_autosubmit in the linked issue (MDL-35672).

          Show
          Andrew Nicols added a comment - Dan - I applied the fixes for help popups, doctonewwindow, and init_autosubmit in the linked issue ( MDL-35672 ).
          Hide
          Derek Chirnside added a comment -

          I am still experiencing intermittent problems. I assumed my problems were insignificant compared to some of the lags and delays others report.
          Chris (above) and others in the forums have offered big courses to work with to see if the issues can be narrowed down.
          Chris also mentioned something that echos the way I feel: not wanting to post data or experiences if there is a possibility that they are slightly wrong and waste time for coders.

          So just curious really. What is happening? Did anyone make any progress with sorting the large courses that people offered for testing? Is the MUC going to help things?

          -Derek

          Show
          Derek Chirnside added a comment - I am still experiencing intermittent problems. I assumed my problems were insignificant compared to some of the lags and delays others report. Chris (above) and others in the forums have offered big courses to work with to see if the issues can be narrowed down. Chris also mentioned something that echos the way I feel: not wanting to post data or experiences if there is a possibility that they are slightly wrong and waste time for coders. So just curious really. What is happening? Did anyone make any progress with sorting the large courses that people offered for testing? Is the MUC going to help things? -Derek
          Hide
          Chris Meyer added a comment -

          It seems the developers' strategy on this one is to patch things up as best they can and then go for a more comprehensive solution. Probably not a bad strategy.

          Indeed, with the tips above and the latest patches, our main problem is in edit mode on big courses for users with IE8. Even so, if one is patient and clicks through some Javascript warnings, one can get by. Nonetheless, we have several districts that will have IE8 for probably another year, so we too are eager for a better solution. The gung-ho teachers are often the ones most bitten by this.

          Chris

          Show
          Chris Meyer added a comment - It seems the developers' strategy on this one is to patch things up as best they can and then go for a more comprehensive solution. Probably not a bad strategy. Indeed, with the tips above and the latest patches, our main problem is in edit mode on big courses for users with IE8. Even so, if one is patient and clicks through some Javascript warnings, one can get by. Nonetheless, we have several districts that will have IE8 for probably another year, so we too are eager for a better solution. The gung-ho teachers are often the ones most bitten by this. Chris
          Hide
          Susan Mangan added a comment -

          I have a course that is unbearable to use. Let me know if you want it for testing - it's all yours

          Show
          Susan Mangan added a comment - I have a course that is unbearable to use. Let me know if you want it for testing - it's all yours
          Hide
          Andrew Nicols added a comment -

          MUC is not a golden bullet and will not help in this case.

          The issues experienced here relate to client-side javascript issues. There are a couple of issues that have already been addressed and will be made available with the release of Moodle 2.3.3 - these should go a long way to improving performance already. There are also a number of other issues which I've been working on and am hoping will also make Moodle 2.3.3 which haven't yet been integrated.

          Show
          Andrew Nicols added a comment - MUC is not a golden bullet and will not help in this case. The issues experienced here relate to client-side javascript issues. There are a couple of issues that have already been addressed and will be made available with the release of Moodle 2.3.3 - these should go a long way to improving performance already. There are also a number of other issues which I've been working on and am hoping will also make Moodle 2.3.3 which haven't yet been integrated.
          Hide
          Mike Tilley added a comment -

          "There are a couple of issues that have already been addressed and will be made available with the release of Moodle 2.3.3"

          can you give an eta for 2.3.3 as this issue is seriously affecting our staff?

          Show
          Mike Tilley added a comment - "There are a couple of issues that have already been addressed and will be made available with the release of Moodle 2.3.3" can you give an eta for 2.3.3 as this issue is seriously affecting our staff?
          Hide
          Dan Poltawski added a comment -

          Hi Mike,

          2.3.3 is due out in two weeks (2 months after 2.3.2, as per out time-based release schedule) http://docs.moodle.org/dev/Process#Minor_release_.28point_release.29_timing

          Show
          Dan Poltawski added a comment - Hi Mike, 2.3.3 is due out in two weeks (2 months after 2.3.2, as per out time-based release schedule) http://docs.moodle.org/dev/Process#Minor_release_.28point_release.29_timing
          Hide
          Mike Tilley added a comment -

          Thanks Dan

          do you know if there is any way of disabling the javascript stuff from within moodle? I know you can disable js in the browser and this really helps with the page load time whilst still keeping the editing functional, but our users are so locked down by group policy that they cant get to their internet options to do this (it would also affect the in house developed intranet systems which are in the same zone).

          Cheers

          Show
          Mike Tilley added a comment - Thanks Dan do you know if there is any way of disabling the javascript stuff from within moodle? I know you can disable js in the browser and this really helps with the page load time whilst still keeping the editing functional, but our users are so locked down by group policy that they cant get to their internet options to do this (it would also affect the in house developed intranet systems which are in the same zone). Cheers
          Hide
          Andrew Nicols added a comment -

          Hi Mike,

          From the work I've done so far, the most affected area is the doctonewwindow setting - if you have this enabled, disable it until 2.3.3 is out. It's a killer for performance at present and gets worse with more sections on your course. This isn't something new in Moodle 2.3 but it seems to be the single worst killer for page performance.

          I wouldn't recommend making changes to core Moodle, but if you do need to then the following suggestions may be useful:

          One change which may help you is to open lib/yui/chooserdialogue/chooserdialogue.js and find the line in setup_chooser_dialogue 'shim : true' - change this to shim : false. I don't think that this will make a massive change, but it won't harm at all.

          There are some other changes you can make which will also improve performance but at the loss of functionality.

          One area which is particularly bad is the help popup code (to show tooltip-style help in Moodle). If you really want to disable this you could open lib/outputrenderers.php, find the render_help_icon() function, and comment out the $this->page->js_init_call() line. This will mean that if a user clicks this help link, they get redirected to the help page.

          If you're still having issues, you can prevent some of the course based JS from happening by opening course/lib.php and finding the include_course_ajax() function. Start by commenting out the $PAGE->requires->yui_module for moodle-core-blocks – this will disable the ability to drag/drop blocks. Another area which will be improved in 2.3.3 is the course toolboxes (show/hide resource, etc). you can disable these by commenting out the code which includes these. You shouldn't lose any functionality with these changes, but they will instead require page reloads.

          You can also comment out the resource_dragdrop line. I wouldn't advise commenting out the section_dragdrop line because when JS is enabled, the non-js move handles are hidden.

          If you do decide to make these changes, I really would advise making them incrementally and doing as few as possible until page performance improves.

          I really wouldn't advise these solutions unless you have no other option and I would try and do the bare minimum of them as the more you do the more functionality will be lost. There will be some good javascript performance improvements in Moodle 2.3, and even more in Moodle 2.4.

          If there is a specific area which does help for you, it would be very helpful if you could comment in this issue.

          Thanks,

          Andrew

          Show
          Andrew Nicols added a comment - Hi Mike, From the work I've done so far, the most affected area is the doctonewwindow setting - if you have this enabled, disable it until 2.3.3 is out. It's a killer for performance at present and gets worse with more sections on your course. This isn't something new in Moodle 2.3 but it seems to be the single worst killer for page performance. I wouldn't recommend making changes to core Moodle, but if you do need to then the following suggestions may be useful: One change which may help you is to open lib/yui/chooserdialogue/chooserdialogue.js and find the line in setup_chooser_dialogue 'shim : true' - change this to shim : false. I don't think that this will make a massive change, but it won't harm at all. There are some other changes you can make which will also improve performance but at the loss of functionality. One area which is particularly bad is the help popup code (to show tooltip-style help in Moodle). If you really want to disable this you could open lib/outputrenderers.php, find the render_help_icon() function, and comment out the $this->page->js_init_call() line. This will mean that if a user clicks this help link, they get redirected to the help page. If you're still having issues, you can prevent some of the course based JS from happening by opening course/lib.php and finding the include_course_ajax() function. Start by commenting out the $PAGE->requires->yui_module for moodle-core-blocks – this will disable the ability to drag/drop blocks. Another area which will be improved in 2.3.3 is the course toolboxes (show/hide resource, etc). you can disable these by commenting out the code which includes these. You shouldn't lose any functionality with these changes, but they will instead require page reloads. You can also comment out the resource_dragdrop line. I wouldn't advise commenting out the section_dragdrop line because when JS is enabled, the non-js move handles are hidden. If you do decide to make these changes, I really would advise making them incrementally and doing as few as possible until page performance improves. I really wouldn't advise these solutions unless you have no other option and I would try and do the bare minimum of them as the more you do the more functionality will be lost. There will be some good javascript performance improvements in Moodle 2.3, and even more in Moodle 2.4. If there is a specific area which does help for you, it would be very helpful if you could comment in this issue. Thanks, Andrew
          Hide
          Dan Bennett added a comment -

          Hi Andrew,

          Are these changes you are suggesting, part of what is included in 2.3.3?
          Just a wild question

          Thanks,

          Dan

          Show
          Dan Bennett added a comment - Hi Andrew, Are these changes you are suggesting, part of what is included in 2.3.3? Just a wild question Thanks, Dan
          Hide
          Andrew Nicols added a comment -

          Hi Dan,

          Most of the areas I've suggested will be addressed for the 2.3.3 release. All of them will be addressed for the 2.4 release. The only one which isn't currently addressed for 2.3.3 is the help tooltip popup system - I had to rewrite this from scratch for 2.4. It is a hit on performance, but with all of the other improvements it shouldn't be too noticeable and it has been around for a number of years.

          I think that part of the problem here has been that the new JS features in 2.3 were just the straw that broke the camel's back. These have been pretty easy to improve, largely thanks to Paul Nicholls. The older features have been around for some time and are actually far worse.

          Andrew

          Show
          Andrew Nicols added a comment - Hi Dan, Most of the areas I've suggested will be addressed for the 2.3.3 release. All of them will be addressed for the 2.4 release. The only one which isn't currently addressed for 2.3.3 is the help tooltip popup system - I had to rewrite this from scratch for 2.4. It is a hit on performance, but with all of the other improvements it shouldn't be too noticeable and it has been around for a number of years. I think that part of the problem here has been that the new JS features in 2.3 were just the straw that broke the camel's back. These have been pretty easy to improve, largely thanks to Paul Nicholls. The older features have been around for some time and are actually far worse. Andrew
          Hide
          Dan Bennett added a comment -

          Great news! Top work guys, I look forward to giving 2.3.3 a run!
          Poor Camel, though.

          Show
          Dan Bennett added a comment - Great news! Top work guys, I look forward to giving 2.3.3 a run! Poor Camel, though.
          Hide
          Sambg added a comment -

          I hate to count my chickens but this is the best news I've had this month. dances around the room singing

          Show
          Sambg added a comment - I hate to count my chickens but this is the best news I've had this month. dances around the room singing
          Hide
          Mike Tilley added a comment -

          @Andrew

          Thanks for this, I've implemented the first 3 and page loading times are down from 45 seconds to 6 ish when editing.

          Much appreciated.

          Show
          Mike Tilley added a comment - @Andrew Thanks for this, I've implemented the first 3 and page loading times are down from 45 seconds to 6 ish when editing. Much appreciated.
          Hide
          Adam Olley added a comment -

          Any progress on this?

          As for some input, IE8 still produces the error dialog asking you to kill the javascript because its unresponsive with the current code up for integration.

          Show
          Adam Olley added a comment - Any progress on this? As for some input, IE8 still produces the error dialog asking you to kill the javascript because its unresponsive with the current code up for integration.
          Hide
          Martin Dougiamas added a comment -

          Just to get some clarification here ... how much of this is still relevant given the fixes that went into 2.3.3 as part of MDL-35672 ?

          Show
          Martin Dougiamas added a comment - Just to get some clarification here ... how much of this is still relevant given the fixes that went into 2.3.3 as part of MDL-35672 ?
          Hide
          Michael de Raadt added a comment -

          I just ran some testing in IE8 and IE10. It looks like the editing page is much more responsive and there is no ongoing activity after the page loads. This is good news.

          I'm not sure how much of this has been fixed in related issues.

          It would be good to see this issue resolved.

          Show
          Michael de Raadt added a comment - I just ran some testing in IE8 and IE10. It looks like the editing page is much more responsive and there is no ongoing activity after the page loads. This is good news. I'm not sure how much of this has been fixed in related issues. It would be good to see this issue resolved.
          Hide
          Nick Gault added a comment -

          Larger courses are still unusable under 2.3.3 using ie8

          Show
          Nick Gault added a comment - Larger courses are still unusable under 2.3.3 using ie8
          Hide
          Jeff Green added a comment -

          I've checked the repository every week and updated my moodle install and my loading times are down for large courses. Can someone please tell me where the doctonewwindow check box is? I've scoured my moodle install with no luck. Thanks.

          Show
          Jeff Green added a comment - I've checked the repository every week and updated my moodle install and my loading times are down for large courses. Can someone please tell me where the doctonewwindow check box is? I've scoured my moodle install with no luck. Thanks.
          Hide
          Chris Meyer added a comment -

          Home > Site Administration > Moodle Docs > Open in new Window checkbox

          Show
          Chris Meyer added a comment - Home > Site Administration > Moodle Docs > Open in new Window checkbox
          Hide
          Chris Meyer added a comment -

          Oops, left one out

          Home > Site Administration > Appearance > Moodle Docs > Open in new Window checkbox

          Chris

          Show
          Chris Meyer added a comment - Oops, left one out Home > Site Administration > Appearance > Moodle Docs > Open in new Window checkbox Chris
          Hide
          Susan Mangan added a comment -

          FYI - we have recently encountered a similar issue with the unresponsive script error with another app at our university and the php developer has proposed the following solution:

          "root cause of this issue is json parsing on IE < 9. It seems that 3Kb json string is the limit at which it starts to take a lot longer. This probably
          varies based on the machine IE runs on (RAM, cpu etc..)"

          Show
          Susan Mangan added a comment - FYI - we have recently encountered a similar issue with the unresponsive script error with another app at our university and the php developer has proposed the following solution: "root cause of this issue is json parsing on IE < 9. It seems that 3Kb json string is the limit at which it starts to take a lot longer. This probably varies based on the machine IE runs on (RAM, cpu etc..)"
          Hide
          Michael de Raadt added a comment -

          Paul/Andrew.

          At some stage this issue was set to "Waiting for peer review", but I don't think new patches have been added.

          Could you please let us know if this issue is ready for review or if the status of this issue should be changed.

          Show
          Michael de Raadt added a comment - Paul/Andrew. At some stage this issue was set to "Waiting for peer review", but I don't think new patches have been added. Could you please let us know if this issue is ready for review or if the status of this issue should be changed.
          Hide
          Andrew Nicols added a comment -

          Michael,

          I'm not sure why this issue was put back into Peer Review. I think it can actually probably be closed now. A number of commits were included as part of this issue already, and a number also in the linked issue (MDL-35672).

          We've already significantly improved JS performance in Moodle 2.3.3 and a number of additional fixes have also made it to to Moodle 2.3.4 already. All of these fixes will be included in Moodle 2.4.

          The only area still unaddressed is the formslib JS which deals with disabledIf - but that was never the key area in this issue anyway.

          Andrew

          Show
          Andrew Nicols added a comment - Michael, I'm not sure why this issue was put back into Peer Review. I think it can actually probably be closed now. A number of commits were included as part of this issue already, and a number also in the linked issue ( MDL-35672 ). We've already significantly improved JS performance in Moodle 2.3.3 and a number of additional fixes have also made it to to Moodle 2.3.4 already. All of these fixes will be included in Moodle 2.4. The only area still unaddressed is the formslib JS which deals with disabledIf - but that was never the key area in this issue anyway. Andrew
          Hide
          Jeff Green added a comment -

          I've kept updated with the patches and it's significantly improved the performance of my large courses under IE8/IE9. Thanks for all the hard work.

          Show
          Jeff Green added a comment - I've kept updated with the patches and it's significantly improved the performance of my large courses under IE8/IE9. Thanks for all the hard work.
          Hide
          Michael de Raadt added a comment -

          Thanks to everyone involved in this.

          Although much of the fixing required to resolve this issue has happened in other issues, I believe that we have now resolved the overarching problem of poor client page loading, particularly in IE.

          For people still experiencing problems, be sure to upgrade your version of Moodle to experience these changes. This and other fixes are available in Moodle 2.4.

          If you are using IE, I also suggest you consider moving to IE10. We plan to stop supporting IE8 with Moodle 2.5.

          Show
          Michael de Raadt added a comment - Thanks to everyone involved in this. Although much of the fixing required to resolve this issue has happened in other issues, I believe that we have now resolved the overarching problem of poor client page loading, particularly in IE. For people still experiencing problems, be sure to upgrade your version of Moodle to experience these changes. This and other fixes are available in Moodle 2.4. If you are using IE, I also suggest you consider moving to IE10. We plan to stop supporting IE8 with Moodle 2.5.
          Hide
          Koen Roggemans added a comment -

          Michael, on Windows XP, the highest supported Microsoft browser is IE8. Extended support of XP ends 8th April 2014.
          It might be necessary for some people to drag the support for IE8 until then. Those people running XP until the end can of course consider installing a different browser. Just something to keep in mind when deciding to drop IE8.

          Show
          Koen Roggemans added a comment - Michael, on Windows XP, the highest supported Microsoft browser is IE8. Extended support of XP ends 8th April 2014. It might be necessary for some people to drag the support for IE8 until then. Those people running XP until the end can of course consider installing a different browser. Just something to keep in mind when deciding to drop IE8.
          Hide
          Nick Gault added a comment -

          Updated to Moodle 2.4 (Build: 20121203) and am still experiencing this issue with some of our larger courses. Are the only one?

          Show
          Nick Gault added a comment - Updated to Moodle 2.4 (Build: 20121203) and am still experiencing this issue with some of our larger courses. Are the only one?
          Hide
          Sambg added a comment -

          I agree Nick,
          It's much improved but not fixed. I've a course that got out of hand before we upgraded. 2.3 almost crippled it. 2.3.4 has made it useable but still not great.

          For reference, loading the page and turning on editing took around 15 seconds in Firefox and Chrome. It took 1m 15s in IE8. rolls eyes

          Show
          Sambg added a comment - I agree Nick, It's much improved but not fixed. I've a course that got out of hand before we upgraded. 2.3 almost crippled it. 2.3.4 has made it useable but still not great. For reference, loading the page and turning on editing took around 15 seconds in Firefox and Chrome. It took 1m 15s in IE8. rolls eyes
          Hide
          Christopher Brower added a comment -

          We upgraded to 2.4 as well and our users with large courses and IE 8 are still experiencing long load times.

          Show
          Christopher Brower added a comment - We upgraded to 2.4 as well and our users with large courses and IE 8 are still experiencing long load times.
          Hide
          Sambg added a comment -

          I'm in the process of backing up a long course and restoring topics to separate
          courses to get round this issue.

          For reference: Clicking in a checkbox is causing a 2.5Ghz cpu to run @ 100% for around 30secs with very little net traffic and no increase in RAM. Saving changes made to a HTML block caused the CPU to max out for well over a minute.

          A dual core 2.5 Ghz runs @ 50-60% for similar time frames on similar tasks.

          This is on firefox. I'm so glad I don't have to use IE.

          Show
          Sambg added a comment - I'm in the process of backing up a long course and restoring topics to separate courses to get round this issue. For reference: Clicking in a checkbox is causing a 2.5Ghz cpu to run @ 100% for around 30secs with very little net traffic and no increase in RAM. Saving changes made to a HTML block caused the CPU to max out for well over a minute. A dual core 2.5 Ghz runs @ 50-60% for similar time frames on similar tasks. This is on firefox. I'm so glad I don't have to use IE.
          Hide
          Andrew Nicols added a comment -

          Sambg: this is a separate and unrelated issue currently being tracked in MDL-35674

          Show
          Andrew Nicols added a comment - Sambg: this is a separate and unrelated issue currently being tracked in MDL-35674