Moodle

The main problem in firefox is this 'black' to "black" replacement that makes code uneditable in firefox. That previous report is http://tracker.moodle.org/browse/MDL-4863 (I should have left some empty space there...)

Has there been any progress on this particular issue? I recently performed an upgrade to 1.8.2, and within the context of one project users are now starting to reporting this issue. Essentially we're triggering some onclick widow.open pages and the script (that worked fine in 1.6) now gets mutated to the non-functional and uneditable in Firefox.

If nobody has time to fix it (back) there is still one work around:

It is possible to select from Edit user profile -> When editing text ... Use standard web forms

(then you don't get editor buttons but it is not a site wide change)

change code or add code, save and change profile back to

Use HTML editor

Thanks for the quick response! I found your forum post (http://moodle.org/mod/forum/discuss.php?d=77744#p345622) on the issue and that got me on the right track again. I think that'll handle my immediate problem. Thanks (again).

I wanted to add a comment to note that this is still happening in version 1.9.2. I'm not sure what Mauno meant by "black to black", but this seems to happen with any event handler as well as causing other strange code changes on just about any javascript that contains quotes. If you add something like
<span onclick="alert('test');">Click Me</span>
it is converted to
<span onclick="function onclick(event) { alert(" test="" );="" }="">Click Me</span>

On top of changing the javascript into something that causes errors in both IE and Firefox, there is a more troubling problem. In Firefox, I can still make edits to the other, non-javascript, content, and when I hit the save changes button, I'm not given any errors, but the changes are not saved. This is a big problem since the user is given no warning that their changes have not been saved.

Not sure how to updated the status of this bug, but it should include 1.9.2 in it's list of affected versions.

I tried this in 1.9, and this happens even with the editor turned off.

If I use "html purifier" instead of kses (see in experimental admin settings), then the background color is kept, but the events are still broken. This is a filter issue ... but really, it's not a good idea, security-wise, to let people put javascript on pages, that's why it's being filtered out.

It's not only a filter issue

• it does not happen in TinyMCE and I have not noticed that code would be changed if standard web forms are used (some activities may have different filters for spans etc)
• if htmlarea converts ' to " inside event handlers it creates invalid tags: "...'...'..." is changed to "..."..."..."
• inserted anonymous functions can make the whole browser (html code) to crash, in this case textareas that have event handlers become uneditable in Firefox
• filters work ok for students and they should never be able to insert javascripts but teachers can insert javascript and even handlers (if allowed)

In moodle 2.0 TinyMCE has the full xhtml rule set that accepts all valid XHTML event handler tags and filters of moodle can cut untrusted content. I hope the default settings still allow teachers to add javascripts and embed media files. For htmlarea turning off editor while inserting javascripts have worked ok and using iframes or uploaded documents with event handlers should be fine.

Here's a full list of XHTML event handlers that moodle should be able to use (through core code, in themes or in some cases pasted to editor):

Window Events (Only valid in body and frameset elements)

onload - Script to be run when a document loads
onunload - Script to be run when a document unloads

Form Element Events (Only valid in form elements)

onchange - Script to be run when the element changes
onsubmit - Script to be run when the form is submitted
onreset - Script to be run when the form is reset
onselect - Script to be run when the element is selected
onblur - Script to be run when the element loses focus
onfocus - Script to be run when the element gets focus

Keyboard Events (Not valid in base, bdo, br, frame, frameset, head, html, iframe, meta, param, script, style, and title elements)

onkeydown - What to do when key is pressed
onkeypress - What to do when key is pressed and released
onkeyup - What to do when key is released

Mouse Events (Not valid in base, bdo, br, frame, frameset, head, html, iframe, meta, param, script, style, and title elements)

onclick - What to do on a mouse click
ondblclick - What to do on a mouse doubleclick
onmousedown - What to do when mouse button is pressed
onmousemove - What to do when mouse pointer moves
onmouseover - What to do when mouse pointer moves over an element
onmouseout - What to do when mouse pointer moves out of an element
onmouseup - What to do when mouse button is released

I think this bug is permanently solved when htmlarea is dropped from moodle and replaced with TinyMCE (moodle 2.0)

I took some time to investigate this bug and found out that this started to happen when code of htmlarea plugin GetHtml ( get-html.js ) was dropped and HTMLArea.indent = function(s, sindentChar) was take to lib/editor/htmlarea.php

I suppose that if htmlarea creates non valid tags by changing "...'...'..." to "..."..."..." it may mess up a lot more html than just script tags. HTMLArea.RegExpCache in get-html.js has 23 different rules and in get-html.js HTMLArea.indent = function(s, sindentChar) uses all those rules with var c = HTMLArea.RegExpCache;

In current htmlarea.php HTMLArea.indent = function(s, sindentChar)
(Modified version of GetHtml plugin's indent)
uses only 8 of those rules and in HTMLArea.prototype.generate = function ()
try { editor.registerPlugin(GetHtml); } catch (e) {}
is not used - I guess it means that plugin GetHtml is not used anymore (unless the code is in some other files...)

I tested also moodle 1.9.3 with the old 1.6.3 htmlarea.php (v 1.3.2.6 2006/07/30 23:16:12) and no anonymous functions were created & event handlers worked ok. There have been many bug fixes to htmlarea.php since that so using that file is not reasonable but fixing this bug would make htmlarea a little more usable. Editor should output valid code and not mess it up.

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

I'm closing this issue as it appears to have become inactive and is probably not relevant to a current supported version. If you are encountering this problem or one similar, please launch a new issue.