When dealing with a non-modal dialogue within a modal dialogue, we should
not update the z-index of the underyling maskNode as it does not belong to
this dialogue.
There is a new theme property 'blockrendermethod' that can be set by the
theme in its config.php and tells Moodle what method it is using to render
blocks in the layout files.
Either blocks, or blocks_for_region.
Then when adding custom block regions to a page content we ensure we use
the same method the theme is using elsewhere.
This is really a hack becuase we (I) didn't properly deprecate
blocks_for_region when I added the blocks method.
* Remove all traces of mathjax from the atto equation editor - it is filter agnostic
* Add a M.core.event module for core events that can be published/subscribed to by plugins (loose coupling)
* Add a FILTER_CONTENT_UPDATED event so plugins can tell the filter system when nodes are added to the page
* Implement a listener for this event in the MathJax filter
* Fire this event from the equation editor and from the glossary filter
* Add a nolink tag to the mathjax filter, so equations will not be processed by the other filters
* Add a smarter throttle function to the equation editor preview updates (Y.throttle is dumb)
In order for a chooser dialogue to be able to fall back to it's non-JS
equivalent, we need to use a different set of styles.
This change makes the chooser dialogue preparation function add a new class
to the body which is utilised in the CSS to accomplish this. When the class
is not present, the dialogue content is displayed inline.
This module supports focusing on a specified Node, or attempting to
determine the Node which caused the displayed the Widget to return focus to
that location.
Most of the moodle core dialogue types should be shown modally, and
centred. They should also be shown on instantiation.
Rather than re-define all of these settings, this patch introduces a new
subclass of M.core.dialogue which sets them up with the same settings.
Various dialogue attributes are optional and are provided by the parent and
not provided as attributes to the dialogue being initted.
As a result, if the setting is not provided during init, we were assuming
that the value would be false rather than checking the real attribute.
The listener was previously confirming, even when the cancel or 'No'
buttons were selected. However, having the default action as 'Confirm'
seems dangerous in this situation, so removing this option entirely.
