Is a priority of "minor" really appropriate for this issue?

The error is a fatal one which prevents the user from seeing their feedback. Surely this is a "major" bug. It makes the quiz unusable with browser security turned on.

Increasing priority as suggested.

Reviewing an affected quiz through the gradebook gives the same error

Some progress about this? Surely this is a "major" bug. Thanks

Any progress on this? Our users are now discovering this bug when they enable browser security.

We are getting tons of teachers asking about this. Any movement on this bug?

Sorry no. I know this is important to a lot of people, but so are a million other things on my todo list.

Tim - Do regressions get any increased priority. This is functionality that was working and now is not working. Is there anything (short of a patch) that I can do to help? It has something to do with the way the fake block is being created in the context of the "secure" page. Peace - Anthony

Regressions do get slightly higher priority, but that still does not get this anywhere near the top of my todo list.

A patch is certainly the most likely way for this to get fixed.

Failing that, an analysis of what exactly is going wrong would help, but if you get that far, I am sure you could make the patch yourself.

With security enabled, students cannot review the quiz or make multiple attempts. By Switching the security to "none", students are able to review the quiz and make multiple attempts.

Just for the benefit of those watching this issue, there have been numerous discussions in the forums about the relative value of taking measures to prevent students from copying and pasting quiz questions. Given the social constructionist pedagogy underlying Moodle, preventing access to information (while sometimes justified) often seems in my own personal estimation to be slightly misguided. It is a matter of debate and I think that this issue should be fixed so that it behaves as it did before but I agree with Tim that there are many other tasks as well. I'll see if I can go in and sort things out about what is really happening but it will involve me taking some time to learn about how pages are constructed post 2.0. It may be a quick job for someone like Sam. Peace - Anthony

Importance of the feature aside - a feature that exists in the UI that is broken leads to users distrusting other parts of the system.

It's important for users to trust the Quiz module because they make high stakes decisions based on it's results.

If the feature is not going to be fixed right away, it would be ideal to remove/hide it so that users don't try to use it and find it broken.

Is this problem related to MDL-23706 (and MDL-26746)?

Trying to do some debugging of this problem... It appears that the problem stems from output having been sent already by the time the "add_fake_block" function is called. Tim, do you know off-hand where that would have been started when the quiz is in secure mode vs. not in secure mode?

Almost certainly at line 104

$accessmanager->setup_secure_page(...

I think the problem is that securewindow_access_rule::setup_secure_page ends with

echo $OUTPUT->header();

The setup method should not do any output, so we should delete that from there, and then review all the pages that call this method.

I understand this issue now, and fixing it properly would clean up a lot of mess. I should be able to do the fix tomorrow, for integration next week, particularly if some people can help me with the testing.

Happy to help with testing. Let me know when its ready.

I would also be more than happy to help with testing.

OK people, please test this. Please text both secure and non-secure quizzes, since the changes may affect both. (Obviously, there should be no changes for non-secure quizzes.)

The message I got back was
Coding error detected, it must be fixed by a programmer: Invalid state passed to moodle_page::set_state. We are in state 2 and state 1 was requested.

I have a meeting to go to and I will try again after that as I don't have git on my server and had to patch the files manually - which means I could have done something I shouldn't have. Or not done something I should have.

I tested your changes on both a secure and non-secure quiz. The problems documented here were resolved, and I could not find any other problems. I could not replicate the problem reported with the gradebook either before or after the changes.

Thanks Mike. That is good enough for me. Submitting for integration.

However, if anyone else can test this between now and Monday, when this is integrated, that would help ensure that there are no un-pleasant side-effects to this fix. Thanks.

Thanks Tim and Mike - I also have tested it and the patch seemed to fix things up just fine. I did not find any unpleasant side effects. Peace - Anthony

My test was successful.

Thank you! You just got me out of hot water with a ton of instructors.

Hi Tim,

The changes look good however you've left being an unused global, securewindow_access_rule::setup_secure_page no longer uses $OUTPUT.
Would you like to fix it up or are you happy for me to remove it during the integration merge?

Cheers
Sam

Please can you remove the unused global during integration. Thanks, and Sorry.

So is the fix in today's weekly build ? If not how can I get to test if ?
(i'm new to the bug tracker)

The key field to look at is the 'Status: ' at the top of this bug report. This is currently going through the Waiting for integration review -> Integration review in progress -> Waiting for testing -> Tested process. If all that works out, it will be included in this week's weekly build, and the bug will then be marked closed. (See http://docs.moodle.org/dev/Process for more details.)

If you want to get the fix early to test it, you need to look at the fields like Pull 2.1 Diff URL: https://github.com/timhunt/moodle/compare/MOODLE_21_STABLE...MDL-28424_21

That shows you what the changes are. If you acutally want to make the changes in your version of Moodle it is easiest if you know how to use the git version control system.

Thanks Tim, this has been integrated now and I fixed up the global during the merge.

Cheers
Sam

Thank you.

Hi Tim,

The patch works great.

However, while testing this issue with "Full screen pop-up with some JavaScript security", I noticed that student could click on the browser's close button and a pop-up "start attempt" window still available. This means a student can view all the quiz questions, close the windows, cancel the attempt, and re-attempt the quiz. I'm not sure if this should be reported as different issue.

I don't believe you can actually do that. I don't think the Cancel button would cancel the attempt once it has been started. It will just hide the Start attempt dialogue. Did you actually try it to see what happened?

When I cancel the attempt, it sets the quiz status to "in progress" with "continue the last attempt" button. And if I clicked on "start attempt", the quiz is not open in the new page.

The pop-up window will worked again after reloading the quiz page.

My comment regarding 'start attempt' with "Full screen pop-up with some JavaScript security" setting is not related to this issue. Therefore I'm going to pass this issue.

Test passed.

Thank you all for fixing this - very much appreciated!

fixes have been rolled merrily up the stream! Thanks everybody!

Hi There,

I am running v2.0 (default plug-ins) and also get this problem. Will this patch work for me too or do I need to upgrade to 2.1?

We have very little support where I am, and I'm not a developer so any help on how I can download the patch and instal it would also be very much welcome. Thanks

Hi Chris,
It's fixed in version 2.1.2, it never has been reported as broken in 2.0. If you're on a standard Moodle, I think upgrading to 2.1 is easier then applying the patch. Support for 2.0 is ended last month completely, so upgrading is a good idea anyway.

Thank you very much for your quick response. I will definately go with the upgrade as advised.