We need to keep these two separate as scripts which define AJAX_SCRIPT
before loading config.php will use a different default renderer and will
return appropriate exceptions which can be parsed by M.core.exception and
M.core.ajaxException correctly.
This also addresses an issue whereby a missing heading could break the
tooltip.
If we set height as well as max-height then there is a potential for
whitespace to be shown at the bottom of the list of choices.
This commit stops removing the height option so that we only rely upon
max-height for dialogue heigh calculation.
The central "content" region on My Home / user profile pages also needs to
be initialised in lib/ajax/blocks.php in order to allow blocks to be
dropped into that region successfully. Some tweaks were also necessary in
order to correct the "content" region's structure in order for drag-drop
to function on this region on these pages.
Non-standard block regions (including the central "content" region
used by My Home and user profile pages) were causing the temporary empty
block region used as a drop target to sometimes appear in the wrong place.
The call to init_requirements_data (which includes the block drag-drop JS)
happens at a late enough stage in page generation that we can simply
pass the context ID through to the JS, so that it can be sent as part of
the AJAX request. This prevents lib/ajax/blocks.php from having to try
to guess the context from the other bits of information it receives, so
block drag-drop should now work everywhere without issues.
In certain modal dialogues, we listen on the Escape key to close a
dialogue. However, this is still passed to the browser. As a result, if the
browser is in full screen mode and that browser respects the escape key as
a means to exit full screen.
As a result, we need to ensure that we listen for the escape key at keydown
rather than keyup, and additionally prevent the default browser behaviour.
This is a workaround to http://yuilibrary.com/projects/yui3/ticket/2532616
and, should that issue be fixed, it should be removed.
Other than shifting the initialisation from course/lib.php to
lib/outputrequirementslib.php, some workarounds/tweaks were required
in order to make it work correctly on admin pages and My Home.
Ideally we shouldn't get into this situation, but in cases where the
generated select element is incorrectly configured, we should try and
handle it gracefully with a warning.
