Moodle

Frames not behaving as expected in Resources, Workshop and MySQL Admin tool

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.8
  • Fix Version/s: 2.0
  • Labels:
    None
  • Environment:
    Server: MacPro, MacOS 10.4.9, Moodle 1.8+ (downloaded from CVS on 26th May), Apache 1.3.33, php 5.2.1, MySQL 5.0.24a
    Client: MacOS 10.4.9, Browsers: Firefox 2.0.0.2, Mozilla 1.7.5, Safari 2.0.4
  • Affected Branches:
    MOODLE_18_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

Description

In MDL-9690 I reported that the Previous and Next activity buttons do not open resources as expected in the bottom frame, but in a new frame at the top. There appears to be similar frame problems in the Workshop activity module and perhaps with the MySQL Admin tool.

The 'Link to file or web site' in 'Add a resource...' menu: see MDL-9690 for details

The Workshop activity module:
When a student or teacher assess an assignment the grading criteria appear in the top frame, and the assignment in the bottom frame. When they finish assessing an assignment they click on 'save', which in the past (moodle 1.6.2) would have taken them back to the list of students to be assessed - i.e. the two frames would close. However, with 1.8 it just opens up another frame, again containing the grading criteria. See the attached JPEG. The same thing happens when viewing assessments.

MySQL Admin tool:
When viewing the MySQL databse via the MySQL Admin tool, phpMyAdmin appear in the lower frame. When clicking on the breadcrumbs in the left of the top frame, moodle behaves as expected. However, when clicking on the users name in the top right, or clicking on 'logout', only the top frame changes, and the bottom frame remains open with the phpMyAdmin still visible. See the attached JPEG.

Issue Links

Activity

Hide
Davo Smith added a comment -

I don't know if this helps anyone, but on my system one solution that seems to work (but is Javascript dependent) is:

in moodle/mod/workshop/locallib.php:

change the line (2053):
<form id="assessmentform" method="post" action="assessments.php">

to:
<form id="assessmentform" method="post" action="assessments.php" onsubmit="this.target='_top'">

I hope that helps to get a little closer to a solution

Show
Davo Smith added a comment - I don't know if this helps anyone, but on my system one solution that seems to work (but is Javascript dependent) is: in moodle/mod/workshop/locallib.php: change the line (2053): <form id="assessmentform" method="post" action="assessments.php"> to: <form id="assessmentform" method="post" action="assessments.php" onsubmit="this.target='_top'"> I hope that helps to get a little closer to a solution
Hide
deraadt added a comment - - edited

Yes, I concur, the Javascript may be necessary. The target attribute is not valid for a form tag in XHTML 1.0 Strict. I think someone decided that all use of frames is evil at some point; this doesn't really help us now.

Another possible solution would be to display the student's submitted HTML content in an iframe, or in a fixed size div (set overflow to auto), within the marking page.

Show
deraadt added a comment - - edited Yes, I concur, the Javascript may be necessary. The target attribute is not valid for a form tag in XHTML 1.0 Strict. I think someone decided that all use of frames is evil at some point; this doesn't really help us now. Another possible solution would be to display the student's submitted HTML content in an iframe, or in a fixed size div (set overflow to auto), within the marking page.
Hide
David Pinyol added a comment -

Is necessary to replace all target="_parent"
with target="$CFG->framename"
in moodle/mod/workshop/viewassessment.php ?

Show
David Pinyol added a comment - Is necessary to replace all target="_parent" with target="$CFG->framename" in moodle/mod/workshop/viewassessment.php ?
Hide
Chris Potter added a comment -

After taking a look at this... I have verified Davo's fix to work (though, yes... javascript dependent). If javascript is indeed required at this point for a "fix", then we need to fix the "Cancel" link and the "Continue" button when reviewing an assessment (these cause the same problem). These both re-direct to the previous page... so why not just use the history.back() function in javascript? No form data has been modified in either situation and the frame is then "removed". This so far is working for us. Did I miss anything??

Lines modified:

  • Davo's fix (above)
  • Line 126 of /mod/workshop/assess.php from:

print_heading("<a $CFG->frametarget href=\"$redirect\">".get_string("cancel")."</a>");

to

print_heading("<a $CFG->frametarget href=\"javascript:history.back()\">".get_string("cancel")."</a>");

  • line 73 of /mod/workshop/viewassessment.php from:

print_continue($redirect);

to

print_continue('javascript:history.back()');

Show
Chris Potter added a comment - After taking a look at this... I have verified Davo's fix to work (though, yes... javascript dependent). If javascript is indeed required at this point for a "fix", then we need to fix the "Cancel" link and the "Continue" button when reviewing an assessment (these cause the same problem). These both re-direct to the previous page... so why not just use the history.back() function in javascript? No form data has been modified in either situation and the frame is then "removed". This so far is working for us. Did I miss anything?? Lines modified:
  • Davo's fix (above)
  • Line 126 of /mod/workshop/assess.php from:
print_heading("<a $CFG->frametarget href=\"$redirect\">".get_string("cancel")."</a>"); to print_heading("<a $CFG->frametarget href=\"javascript:history.back()\">".get_string("cancel")."</a>");
  • line 73 of /mod/workshop/viewassessment.php from:
print_continue($redirect); to print_continue('javascript:history.back()');
Hide
Martin Dougiamas added a comment -

Bulk-assigning 15 Workshop bugs to David M

Show
Martin Dougiamas added a comment - Bulk-assigning 15 Workshop bugs to David M
Hide
Petr Škoda (skodak) added a comment -

Hello, the frames are deprecated web feature, however we have improved the support a bit in 2.0. by default frames are disabled in mod/url and resources, but they should work fine now.

Thanks for the report.

Petr Skoda

Show
Petr Škoda (skodak) added a comment - Hello, the frames are deprecated web feature, however we have improved the support a bit in 2.0. by default frames are disabled in mod/url and resources, but they should work fine now. Thanks for the report. Petr Skoda

Dates

  • Created:
    Updated:
    Resolved: