Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: HTML Editor (TinyMCE)
    • Labels:
      None
    • Environment:
      All
    • Affected Branches:
      MOODLE_15_STABLE
    • Rank:
      8384

      Description

      When a page loads in IE the editor status line contains the whole path to the textarea which can be very long, for example on forum/post.php you get

      Path: body»div#page»div#content»div#forum-post.forum»table.generalbox»tbody»tr»td.generalboxcontent»form»table»tbody»tr»td»input

      Only after you click in the editor window does the status line change to the sensible Path: body

        Activity

        Hide
        Martin Dougiamas added a comment -

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Wednesday, 9 February 2005, 06:15 PM:

        This actually is not editor's bug . Although you'll need to confirm this resolution for me:

        Remove style import line from print_header function (1149) so that the line looks like this:

        // Add a stylesheet for the HTML editor

        $meta = $meta\n;

        This stylesheet doesn't need to be loaded at the head of the document since editor it self loads this stylesheet.

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Wednesday, 9 February 2005, 06:17 PM:

        I'm beginning to hate this damn bug tracker too #%&??

        From Gustav Delius (gwd2 at york.ac.uk) Thursday, 10 February 2005, 01:56 AM:

        The print_header() function does not appear to have such a line. Maybe the bug tracker ate some important bit from your post. Please explain again.

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Thursday, 10 February 2005, 05:04 PM:

        You're right.

        The new print_header doesn't include this line. The new one uses $CFG->stylesheets and I can't find where the values in it been set???? But where ever these are set the htmlarea.css shouldn't be in that list.

        From Gustav Delius (gwd2 at york.ac.uk) Thursday, 10 February 2005, 06:37 PM:

        These are set in theme_setup() in weblib.php but in any case they do not include htmlarea.css. So this bug must have a different origin.

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Thursday, 10 February 2005, 11:09 PM:

        I'll have to test the latest version. I'll change resolution back to none.

        If you find this before I do (the bug not the css - file), let me know.

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 05:29 AM:

        I've added this.focusEditor in HTMLArea.prototype.updateToolbar function at line 1043.

        This set the focus on the editor in IE, which been lost when setfocus fired up in body tags onload event. And when focus was lost from the editor, the getParent element function read tags also from parent document (since the document in iframe doesn't really exist).

        Ain't IE just grand

        From Gustav Delius (gwd2 at york.ac.uk) Saturday, 12 February 2005, 07:25 AM:

        That is not a very satisfactory fix because now the focus is always in the HTML area and not in the field in which it is supposed to be, which for example when setting up a new resource or activity would be the name field, the first field in the form.

        What changed between 1.4 and 1.5 which has led to this bug?

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 07:45 AM:

        As far as I know this is present in version 1.4?

        From Gustav Delius (gwd2 at york.ac.uk) Saturday, 12 February 2005, 05:54 PM:

        Janne, you are right, the bug was already there in Moodle 1.4, at least in the later versions of that branch. I have no idea when it started. It was not so noticeable in 1.4 because there were fewer tags.

        I have experimented with taking out the call to editor.updateToolbar() from the end of HTMLArea.prototype.generate. That seems to work beautifully. Now the status bar shows an empty path until the user focuses on the editor window.

        I think that would be a good resolution of this issue? Do you agree?

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 06:29 PM:

        That'll be perfect :-D

        I'll make the changes and check it in. BTW I found a search and replace plugin for HTMLArea. I think this is a must have feature...

        From Janne Mikkonen (janne.mikkonen at julmajanne.com) Sunday, 13 February 2005, 12:31 AM:

        Should be fixed now...

        From Gustav Delius (gwd2 at york.ac.uk) Sunday, 13 February 2005, 07:33 PM:

        Works well. Thanks.

        Show
        Martin Dougiamas added a comment - From Janne Mikkonen (janne.mikkonen at julmajanne.com) Wednesday, 9 February 2005, 06:15 PM: This actually is not editor's bug . Although you'll need to confirm this resolution for me: Remove style import line from print_header function (1149) so that the line looks like this: // Add a stylesheet for the HTML editor $meta = $meta\n; This stylesheet doesn't need to be loaded at the head of the document since editor it self loads this stylesheet. From Janne Mikkonen (janne.mikkonen at julmajanne.com) Wednesday, 9 February 2005, 06:17 PM: I'm beginning to hate this damn bug tracker too #%&?? From Gustav Delius (gwd2 at york.ac.uk) Thursday, 10 February 2005, 01:56 AM: The print_header() function does not appear to have such a line. Maybe the bug tracker ate some important bit from your post. Please explain again. From Janne Mikkonen (janne.mikkonen at julmajanne.com) Thursday, 10 February 2005, 05:04 PM: You're right. The new print_header doesn't include this line. The new one uses $CFG->stylesheets and I can't find where the values in it been set???? But where ever these are set the htmlarea.css shouldn't be in that list. From Gustav Delius (gwd2 at york.ac.uk) Thursday, 10 February 2005, 06:37 PM: These are set in theme_setup() in weblib.php but in any case they do not include htmlarea.css. So this bug must have a different origin. From Janne Mikkonen (janne.mikkonen at julmajanne.com) Thursday, 10 February 2005, 11:09 PM: I'll have to test the latest version. I'll change resolution back to none. If you find this before I do (the bug not the css - file), let me know. From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 05:29 AM: I've added this.focusEditor in HTMLArea.prototype.updateToolbar function at line 1043. This set the focus on the editor in IE, which been lost when setfocus fired up in body tags onload event. And when focus was lost from the editor, the getParent element function read tags also from parent document (since the document in iframe doesn't really exist). Ain't IE just grand From Gustav Delius (gwd2 at york.ac.uk) Saturday, 12 February 2005, 07:25 AM: That is not a very satisfactory fix because now the focus is always in the HTML area and not in the field in which it is supposed to be, which for example when setting up a new resource or activity would be the name field, the first field in the form. What changed between 1.4 and 1.5 which has led to this bug? From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 07:45 AM: As far as I know this is present in version 1.4? From Gustav Delius (gwd2 at york.ac.uk) Saturday, 12 February 2005, 05:54 PM: Janne, you are right, the bug was already there in Moodle 1.4, at least in the later versions of that branch. I have no idea when it started. It was not so noticeable in 1.4 because there were fewer tags. I have experimented with taking out the call to editor.updateToolbar() from the end of HTMLArea.prototype.generate. That seems to work beautifully. Now the status bar shows an empty path until the user focuses on the editor window. I think that would be a good resolution of this issue? Do you agree? From Janne Mikkonen (janne.mikkonen at julmajanne.com) Saturday, 12 February 2005, 06:29 PM: That'll be perfect :-D I'll make the changes and check it in. BTW I found a search and replace plugin for HTMLArea. I think this is a must have feature... From Janne Mikkonen (janne.mikkonen at julmajanne.com) Sunday, 13 February 2005, 12:31 AM: Should be fixed now... From Gustav Delius (gwd2 at york.ac.uk) Sunday, 13 February 2005, 07:33 PM: Works well. Thanks.
        Hide
        Michael Blake added a comment -

        assign to a valid user

        Show
        Michael Blake added a comment - assign to a valid user

          People

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

            Dates

            • Created:
              Updated:
              Resolved: