Since version 6.4 and later, TinyMCE had a feature `ui_mode: split`.
It enables support for editors in scrollable containers,
and Moodle has some pages, especially the course pages, that are using the scrollable containers.
Therefore, all workaround that is addressed should be replaced by the feature to avoid future problems
regarding the overflow and the z-index issues.
TinyMCE has a default entity_encoding 'named',
which causes text with diacritic symbols to be converted to HTML entities,
e.g. pâté will be convert to pâté
That will be a problem with the Glossary auto-linking filter if a course has a text concept like pâté,
then the filter will likely fail to get the text concept.
Changing the TinyMCE entity_encoding to 'raw' will resolve the problem.
This is in keeping with other Editors such as Atto and resolves an issue
where DOM Purification incorrectly identifies HTML-like string content
as an HTML tag with a JS variable.
Moodle already performs XSS sanitisation using HTML Purifier in PHP.
The boost theme makes the TinyMCE editor rendered in a scrollable container,
scrolling the editor’s container will cause TinyMCE UI elements to be detached from the anchor.
Therefore, to keep the tinyMCE menu in the correct position,
adjustments must be made on the page drawers style.
When using TinyMCE editor in Safari browsers, a problem may occur where the dialogue
windows (such as modal dialogs) overlap with page drawers due to a specific behavior
in Safari's rendering. This function addresses the issue by adjusting the CSS overflow
property of the page drawers, ensuring they do not obscure the dialogue windows.
When an editor is renderer initially invisible to the browser, e.g.
the forum "Add discussion" form, it has a `clientHeight` value of
zero. We can approximate an alternative value based on the number
of rows in the textarea.
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
Ensure the same heading tags are available as those defined in the
editor block formats configuration (c51b7e2c).
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
This is a workaround for an upstream bug which I have not been able to
reproduce outside of Moodle whereby the editor.contentWindow does not
match the editor.iframeElement.contentWindow when it should.
This issue only seems to affect Firefox, and it may even be a bug in
Firefox. It can only be reproduced when using a fresh browser which has
never had a TinyMCE window open.
The TinyMCE menu has a significant issue with the Overflow style,
and the Boost theme heavily uses Overflow for drawer navigation.
Nest the dropdown menu container into the parent editor container makes it work correctly.
Co-authored-by: davewoloszyn <david.woloszyn@moodle.com>
Co-authored-by: xr0master <xr0master@gmail.com>
Added a few functions to remove the toolbar button, menubar and sub-menu items.
One of the implementations is to remove the justify alignment in the toolbar and
the sub-menu items to aid the accessibility aspect of the TinyMCE editor.
We created a list of placeholder selectors in placeholderSelectors option.
The purpose of this list is to indicate the contents that are only shown
in the editor and not to the users, by that way, we can decide to apply or
not to apply rules, styles, etc... to these contents
jQuery submit events do not trigger the native submit event, and
therefore the TinyMCE submit listener is not called. This means that the
tinymce.triggerSave() function is not called, and the editor content is
not saved.
To work around this, if there is a form for the Node that the editor is
attached to, the jQuery submit event is listened to and the save event
called.
Unfortunately it is not possible to use a global jQuery submit listener
added to the document to save all editors on the page.
In some cases, this is too late because the bubbling process means that
a child node consumer may attempt to consume the data before the
delegated handler is called for the document.
This commit removes several contentious formatting options for now,
pending further consideration, in particular it removes:
- forecolor
- backcolor
- fontfamily
- styles
The two color plugins are written in such a way that the chosen colour
is embedded into a style tag in the generated content. This is not
ideal as it removes these decisions away from theme developers and upon
theme changes to a site, is likely to lead to inaccessible and/or broken
content.
We feel that a new colour plugin will be required which links to known
colour style classes within the theme to allow a subset of colours which
are guaranteed to work with the theme.
The fontfamily plugin is removed pending further administrator
configuration in a future release.
In the case of the 'styles' plugin, this duplicates large parts of the
Format menu into which it is placed but does so in a way that does
respect the configuration of other areas - for example the block_formats
tag is ignored in this menu.
Part of MDL-75966
Sara Arjona