Moodle
  1. Moodle
  2. MDL-6649

HTML Editor in essay question unreliable

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6, 1.6.1, 1.6.2
    • Fix Version/s: 1.6.3, 1.7
    • Component/s: Questions
    • Labels:
      None
    • Environment:
      Internet Explorer on Windows
    • Rank:
      28268

      Description

      Multiple instances of the HTML editor cause Internet Explorer to function unreliably: the editor may be displayed with just a tool bar and no text area, or IE may lockup completely. This causes big problems for students taking quizzes with Essay questions, especially if multiple essay questions are loaded in one quiz.

      When we originally wrote the essay question at Humboldt State, we did not enable the HTML editor for this reason.

      See http://moodle.org/mod/forum/discuss.php?d=54574 for more information about the problems the HTML editor can cause when used in essay questions.

      I would suggest either not displaying the editor in quiz essay questions at all: loading multiple instances of the editor on Firefox can also slow down the page load a good deal, or putting in a browser detection function to hide it when the user is using Internet Explorer on Windows.

      Perhaps another option would be a config option in the Quiz module to use or not use the HTML editor in essay questions.

        Issue Links

          Activity

          Hide
          Pierre Pichet added a comment -

          I had opened a simple quiz with 4 essay questions.
          The 4 HTML editors function well with no special delays.
          I am using Explorer 6 on a 500mHz pentium with 500 megabytes of ram.
          http://132.208.141.198/moodle_head_exp/ you could log as teacher if you want
          I have created a teacher user:moodle pw :moodle that you could use
          Could it be related to your machine capacity or Explorer version?

          Show
          Pierre Pichet added a comment - I had opened a simple quiz with 4 essay questions. The 4 HTML editors function well with no special delays. I am using Explorer 6 on a 500mHz pentium with 500 megabytes of ram. http://132.208.141.198/moodle_head_exp/ you could log as teacher if you want I have created a teacher user:moodle pw :moodle that you could use Could it be related to your machine capacity or Explorer version?
          Hide
          Pierre Pichet added a comment -

          I will explore on http://132.208.141.198/moodle_head_exp/ either

          the option for opening another window with the html on
          or
          with a javascript control offering the possibilty to change in the question diplay to have or not the HTML editor for individual question .
          I will comment here when they will be available to test (probably tomorrow)

          Show
          Pierre Pichet added a comment - I will explore on http://132.208.141.198/moodle_head_exp/ either the option for opening another window with the html on or with a javascript control offering the possibilty to change in the question diplay to have or not the HTML editor for individual question . I will comment here when they will be available to test (probably tomorrow)
          Hide
          Tim Hunt added a comment -

          I don't think this is the right approach.

          To start with, if I was asking essay questions, I would set the quiz to 1 question per page, to encourage students to concentrate on one thing at a time.

          Second, the Moodle already has other ways to control whether the rich text editor is used.

          Third, doing browser detection here is just evil.

          Forth, people who really care about this can hack their own install.

          Show
          Tim Hunt added a comment - I don't think this is the right approach. To start with, if I was asking essay questions, I would set the quiz to 1 question per page, to encourage students to concentrate on one thing at a time. Second, the Moodle already has other ways to control whether the rich text editor is used. Third, doing browser detection here is just evil. Forth, people who really care about this can hack their own install.
          Hide
          Michael Penney added a comment -

          Tim, I really think not fixing is the wrong approach here.

          Why not err on the side of providing the most stable user experience possible, turn off the HTML editor for all essay questions by default, and let the folks who want to use the editor for essay questions hack <em>their</em> installs?

          Since the number of institutions who can require their users to use Firefox is likley much smaller than the number of institutions who cannot, turning of the editor where it is known to cause problems seems to me the better design for the most users.

          Your points are all entirely valid from an engineering perspective. However, from a user/support perspective:

          Many users <b>will</b> be using IE in most institutions, and it <b>will</b> fail intermittantly when multiple instances of the HTML editor are used. We've been trying to debug the IE failing issue here for years at Humboldt State, and we can't find any specific browser settings that cause it, it seems entirely intermittant.

          Moodle does enable turning off the editor on a per-user or site-wide basis, however this is hard to explain to users, and results in a drastic fix from a user's perspective (users can't use the editor anywhere or have to remember to turn it off before they start a quiz) when the main problem is localized to modules where multiple copies of the editor are displayed.

          Faculty can be told to use on question at a time when using essay questions because the editor may fail, but this results in the technology driving the pedagogy, which I feel is backwards.

          It also results in a user's impression that the system is not stable.

          I don't now if OU requires Firefox, and the problem with IE is intermittant, but if 90% of the OU's students have intermittant problems entering essay questions, and 10% of them call your help desk, that is going to generate thousands of calls that your support folks will have to deal with, and thousands of students who have problems entering their essay questions.

          Show
          Michael Penney added a comment - Tim, I really think not fixing is the wrong approach here. Why not err on the side of providing the most stable user experience possible, turn off the HTML editor for all essay questions by default, and let the folks who want to use the editor for essay questions hack <em>their</em> installs? Since the number of institutions who can require their users to use Firefox is likley much smaller than the number of institutions who cannot, turning of the editor where it is known to cause problems seems to me the better design for the most users. Your points are all entirely valid from an engineering perspective. However, from a user/support perspective: Many users <b>will</b> be using IE in most institutions, and it <b>will</b> fail intermittantly when multiple instances of the HTML editor are used. We've been trying to debug the IE failing issue here for years at Humboldt State, and we can't find any specific browser settings that cause it, it seems entirely intermittant. Moodle does enable turning off the editor on a per-user or site-wide basis, however this is hard to explain to users, and results in a drastic fix from a user's perspective (users can't use the editor anywhere or have to remember to turn it off before they start a quiz) when the main problem is localized to modules where multiple copies of the editor are displayed. Faculty can be told to use on question at a time when using essay questions because the editor may fail, but this results in the technology driving the pedagogy, which I feel is backwards. It also results in a user's impression that the system is not stable. I don't now if OU requires Firefox, and the problem with IE is intermittant, but if 90% of the OU's students have intermittant problems entering essay questions, and 10% of them call your help desk, that is going to generate thousands of calls that your support folks will have to deal with, and thousands of students who have problems entering their essay questions.
          Hide
          Pierre Pichet added a comment -

          A first working prototype is available for testing see
          http://moodle.org/mod/forum/discuss.php?d=54574#250237

          Show
          Pierre Pichet added a comment - A first working prototype is available for testing see http://moodle.org/mod/forum/discuss.php?d=54574#250237
          Hide
          Pierre Pichet added a comment -

          There is no hacking necessary and it is working either with Explorer or Firefox.
          The default value is HTML editor off.
          No changes are necessary in the database in this first version.
          The editor change when you submit a question.

          Show
          Pierre Pichet added a comment - There is no hacking necessary and it is working either with Explorer or Firefox. The default value is HTML editor off. No changes are necessary in the database in this first version. The editor change when you submit a question.
          Hide
          N Hansen added a comment -

          PIerre-I tested your new thing early this morning. Strange things happened to the page when I switched and it was not clear what the difference between the four options was.

          I agree with Tim, not that you should put only 1 essay question per page necessarily from a pedagogical point of view, but simply that this is something teachers can already control with page breaks.

          However, that said, a middle ground might be this. Perhaps rather than give students control over whether to use the editor (if they are confused about enabling the editor sitewide as Michael says they certainly will be confused when they encounter it in the middle of a quiz), put it in the teacher's hands. If the teacher wants to use the editor, let them enable it for the entire quiz or not in the quiz configuration, or if you prefer, in each question's configuration. Add a little help item next to the option explaining the pros and cons of using the editor or not, and let the teachers decide. It's better if you are going to have to explain this at all then it should be the smaller number of faculty who need to be explained to, not the entire student population which is what will need to happeni if you implement Pierre's hack.

          Also, Pierre's hack makes the behavior of Moodle inconsistent. Students will wonder why they have this choice in the quiz and not elsewhere in Moodle.

          Show
          N Hansen added a comment - PIerre-I tested your new thing early this morning. Strange things happened to the page when I switched and it was not clear what the difference between the four options was. I agree with Tim, not that you should put only 1 essay question per page necessarily from a pedagogical point of view, but simply that this is something teachers can already control with page breaks. However, that said, a middle ground might be this. Perhaps rather than give students control over whether to use the editor (if they are confused about enabling the editor sitewide as Michael says they certainly will be confused when they encounter it in the middle of a quiz), put it in the teacher's hands. If the teacher wants to use the editor, let them enable it for the entire quiz or not in the quiz configuration, or if you prefer, in each question's configuration. Add a little help item next to the option explaining the pros and cons of using the editor or not, and let the teachers decide. It's better if you are going to have to explain this at all then it should be the smaller number of faculty who need to be explained to, not the entire student population which is what will need to happeni if you implement Pierre's hack. Also, Pierre's hack makes the behavior of Moodle inconsistent. Students will wonder why they have this choice in the quiz and not elsewhere in Moodle.
          Hide
          Pierre Pichet added a comment -

          Please note that i was working on it this morning...so the inconsistent behavior was a NORMAL ONE...
          When I think that this is a finished product, I will put my solution on moodle docs and if somebody thinks its worth it, he could come back and vote for it.
          In the meantime I gain a better knowledge of quiz and attemps.

          Show
          Pierre Pichet added a comment - Please note that i was working on it this morning...so the inconsistent behavior was a NORMAL ONE... When I think that this is a finished product, I will put my solution on moodle docs and if somebody thinks its worth it, he could come back and vote for it. In the meantime I gain a better knowledge of quiz and attemps.
          Hide
          Pierre Pichet added a comment -

          What will be my final version unless somebody want to use it is available on http://132.208.141.198/moodle_head_exp/
          All the code modifications necessary are were done in the files
          essay/display.html and
          essay/questiontype.php function function print_question_formulation_and_controls().
          As far as I understand the new lines of code could be used in 1.6 without modification.

          Show
          Pierre Pichet added a comment - What will be my final version unless somebody want to use it is available on http://132.208.141.198/moodle_head_exp/ All the code modifications necessary are were done in the files essay/display.html and essay/questiontype.php function function print_question_formulation_and_controls(). As far as I understand the new lines of code could be used in 1.6 without modification.
          Hide
          N Hansen added a comment -

          Perhaps a solution can be found in this other issue I have linked?

          Show
          N Hansen added a comment - Perhaps a solution can be found in this other issue I have linked?
          Hide
          Tim Hunt added a comment -

          OK, by popular demand, I will do something about this.

          The solution I am going to use is to use the rich-text editor for the first essay question on any page, but not for any of the others. That is easy to implement and works, without losing the benefit of the rich text editor in some cases.

          Show
          Tim Hunt added a comment - OK, by popular demand, I will do something about this. The solution I am going to use is to use the rich-text editor for the first essay question on any page, but not for any of the others. That is easy to implement and works, without losing the benefit of the rich text editor in some cases.
          Hide
          Tim Hunt added a comment -

          OK. I have checked that fix in.

          Show
          Tim Hunt added a comment - OK. I have checked that fix in.
          Hide
          Pierre Pichet added a comment -

          I do think that multiple HTML editor can be unreliable because of two lines in lib/weblib.php where the HTML or textarea are defined
          line 3593
          $str .= '<textarea class="form=textarea" id="edit-'. $name .'" name="'. $name .'" rows="'. $rows .'" cols="'. $cols .'">';
          line 3632
          echo "$editor = new HTMLArea('edit-$name');\n";
          edit-$name as name of the editor can be intrerpreted in javascript as edit minus $name value used.
          When the browser interpret the events coming from the HTML it most genrally used the id to locate the object.
          If you change edit- to edit_ there wil be no confusion in the browser in interperting the events.
          I have made this change and eveything work fine with Explorer, Netscape or Firefox.
          This is the only occurence of the string edit- in the moodle code related to questions or HTML editor.
          I discovered this problem when I was working on a javascript to analyse the user input when editing calculated question.

          Show
          Pierre Pichet added a comment - I do think that multiple HTML editor can be unreliable because of two lines in lib/weblib.php where the HTML or textarea are defined line 3593 $str .= '<textarea class="form=textarea" id="edit-'. $name .'" name="'. $name .'" rows="'. $rows .'" cols="'. $cols .'">'; line 3632 echo "$editor = new HTMLArea('edit-$name');\n"; edit-$name as name of the editor can be intrerpreted in javascript as edit minus $name value used. When the browser interpret the events coming from the HTML it most genrally used the id to locate the object. If you change edit- to edit_ there wil be no confusion in the browser in interperting the events. I have made this change and eveything work fine with Explorer, Netscape or Firefox. This is the only occurence of the string edit- in the moodle code related to questions or HTML editor. I discovered this problem when I was working on a javascript to analyse the user input when editing calculated question.
          Hide
          Tim Hunt added a comment -

          If your javascript is getting the textarea using the dom-standard function document.getElementById(), then the - in the id does not matter.

          Show
          Tim Hunt added a comment - If your javascript is getting the textarea using the dom-standard function document.getElementById(), then the - in the id does not matter.
          Hide
          N Hansen added a comment -

          Tim-For those of us who need multiple html editors on a page, could you please tell us how to undo t his change so that it continues to work like it always does?

          Show
          N Hansen added a comment - Tim-For those of us who need multiple html editors on a page, could you please tell us how to undo t his change so that it continues to work like it always does?
          Hide
          Tim Hunt added a comment -

          By the magic of this bug tracker, switch to the 'Verson Control' tab instead of 'Comments'. (The info also appears on the 'All' tab.)

          That shows you exactly which files I changed to fix this bug. Because I fixed it in 1.6+ and 1.7dev, each file is listed twice. If you then click on, for example, the '(+6 - 2 lines)' link next to the file 'question/type/essay/questiontype.php', you can see exactly what I changed in that file, and hence you can see how to undo the change.

          How cool is that?

          Show
          Tim Hunt added a comment - By the magic of this bug tracker, switch to the 'Verson Control' tab instead of 'Comments'. (The info also appears on the 'All' tab.) That shows you exactly which files I changed to fix this bug. Because I fixed it in 1.6+ and 1.7dev, each file is listed twice. If you then click on, for example, the '(+6 - 2 lines)' link next to the file 'question/type/essay/questiontype.php', you can see exactly what I changed in that file, and hence you can see how to undo the change. How cool is that?
          Hide
          Pierre Pichet added a comment -

          about javascript.
          I was trying to use the same structure that is used on calculated/editquestion.html
          with(document.theform) {
          if (formula0.value=='')

          { alert('<?php print_string("missingformula","quiz") ?>'); return false; /* It could perhaps be an idea to parse the formula here * but as it is necessary at the server anyway, we can * it leave like this for the moment. */ }

          else if (''!=defaultunit.value && !isNaN(defaultunit.value))

          { alert('<?php print_string("unitmustnotbenumeric","quiz") ?>'); return false; }

          else if (isNaN(tolerance0.value))

          { alert('<?php print_string("tolerancemustbenumeric","quiz") ?>'); return false; }

          else if ('2' == document.theform['correctanswerformat[]'].value
          && '0' == document.theform['correctanswerlength[]'].value) {
          alert('<?php print_string("zerosignificantfiguresnotallowed","quiz") ?>');

          and in this case having edit-questiontext or edit_questiontext matters.
          document.theform.edit_questiontext.value can be tested.
          but not document.theform.edit-questiontext.value
          So for a better Moodle code...

          Show
          Pierre Pichet added a comment - about javascript. I was trying to use the same structure that is used on calculated/editquestion.html with(document.theform) { if (formula0.value=='') { alert('<?php print_string("missingformula","quiz") ?>'); return false; /* It could perhaps be an idea to parse the formula here * but as it is necessary at the server anyway, we can * it leave like this for the moment. */ } else if (''!=defaultunit.value && !isNaN(defaultunit.value)) { alert('<?php print_string("unitmustnotbenumeric","quiz") ?>'); return false; } else if (isNaN(tolerance0.value)) { alert('<?php print_string("tolerancemustbenumeric","quiz") ?>'); return false; } else if ('2' == document.theform['correctanswerformat[]'].value && '0' == document.theform['correctanswerlength[]'].value) { alert('<?php print_string("zerosignificantfiguresnotallowed","quiz") ?>'); and in this case having edit-questiontext or edit_questiontext matters. document.theform.edit_questiontext.value can be tested. but not document.theform.edit-questiontext.value So for a better Moodle code...
          Hide
          Tim Hunt added a comment -

          As I said before, the sandard javascript way to do document.theform.edit-questiontext.value is document.getElementById('edit-questiontext'); Not only is it standard, but it also works. What's to lose by using the syntax I recommend?

          Show
          Tim Hunt added a comment - As I said before, the sandard javascript way to do document.theform.edit-questiontext.value is document.getElementById('edit-questiontext'); Not only is it standard, but it also works. What's to lose by using the syntax I recommend?
          Hide
          Don Hinkelman added a comment -

          I would like to confirm this bug--with this experience. Today, in an end of term exam with 80 students, we included two essay questions on the test. Two months ago we had one essay question with no problem. At the end of the test, students saved their answers and lost all data in the essay questions. We also had another problem when students clicked "save and do not submit" but that's another story. Searching through this bug-issue tracker found this posting which explains what happened. We operate moodle version 1.6.2 running IE Explorer 6 and the HTML editor turned "on" for the site. The multiple HTML editors somehow conflicted and blanked all essay data on saving. From reading these comments, I believe if we had upgraded to version 1.6.3 or greater we would not have had this problem. Normally we only use stable Moodle versions and upgrade twice a year between semesters. This experience teaches us to upgrade more frequently within a stable series of a version. Is this a correct assesment?

          Show
          Don Hinkelman added a comment - I would like to confirm this bug--with this experience. Today, in an end of term exam with 80 students, we included two essay questions on the test. Two months ago we had one essay question with no problem. At the end of the test, students saved their answers and lost all data in the essay questions. We also had another problem when students clicked "save and do not submit" but that's another story. Searching through this bug-issue tracker found this posting which explains what happened. We operate moodle version 1.6.2 running IE Explorer 6 and the HTML editor turned "on" for the site. The multiple HTML editors somehow conflicted and blanked all essay data on saving. From reading these comments, I believe if we had upgraded to version 1.6.3 or greater we would not have had this problem. Normally we only use stable Moodle versions and upgrade twice a year between semesters. This experience teaches us to upgrade more frequently within a stable series of a version. Is this a correct assesment?
          Hide
          Tim Hunt added a comment -

          Yes, more stable upgrades on stable branches is recommended. Not only to they contain bug fixes. They also contain security fixes.

          However, as will all upgrades, take the sensible precautions. Try updating a copy of your live site first and do a bit of checking of the upgraded site before updating the real system. Stable branches should be just that, stable, but there is no point taking unnecessary risks.

          Show
          Tim Hunt added a comment - Yes, more stable upgrades on stable branches is recommended. Not only to they contain bug fixes. They also contain security fixes. However, as will all upgrades, take the sensible precautions. Try updating a copy of your live site first and do a bit of checking of the upgraded site before updating the real system. Stable branches should be just that, stable, but there is no point taking unnecessary risks.
          Hide
          Don Hinkelman added a comment -

          Tim wrote: "Yes, more stable upgrades on stable branches is recommended..."

          Unfortunately, I assumed version 1.6.2+ was a stable release. Shouldn't we keep the "beta" suffix to our releases a while longer? This is not the first time something catastrophic happened in a supposedly stable release. By catastrophic, I mean total loss of data in the midst of a student end-of-term exam.

          Show
          Don Hinkelman added a comment - Tim wrote: "Yes, more stable upgrades on stable branches is recommended..." Unfortunately, I assumed version 1.6.2+ was a stable release. Shouldn't we keep the "beta" suffix to our releases a while longer? This is not the first time something catastrophic happened in a supposedly stable release. By catastrophic, I mean total loss of data in the midst of a student end-of-term exam.
          Hide
          Tim Hunt added a comment -

          Do you remember what happened with the 1.6 release? It was scheduled for realease in January, but did not come out until July because they didn't want to drop the beta suffix until it was ready. So no, just delaying releases indefinitely is not a solution. Especially when you have people trying to plan in advance when to do adopt a new release. We should not really be having this conversation in the tracker. If you want to continue it, please do so in the forums.

          Show
          Tim Hunt added a comment - Do you remember what happened with the 1.6 release? It was scheduled for realease in January, but did not come out until July because they didn't want to drop the beta suffix until it was ready. So no, just delaying releases indefinitely is not a solution. Especially when you have people trying to plan in advance when to do adopt a new release. We should not really be having this conversation in the tracker. If you want to continue it, please do so in the forums.
          Hide
          Don Hinkelman added a comment -

          Yes, that's right. Let's move the conversation here... http://moodle.org/mod/forum/discuss.php?d=67448

          Show
          Don Hinkelman added a comment - Yes, that's right. Let's move the conversation here... http://moodle.org/mod/forum/discuss.php?d=67448

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: