Snippet options were not receiving proper data parameter on
instantiantion due to a websitepocalypse wrong adaptation. Those
data are parameters to tweak an option behavior, directly defined
on the option's <div/> in the XML. By mistake, they were now taken
on the child <li/> element (main DOM element of the option).
A visual example of the bug is the overlay colorpicker displaying
"Background Color" as a title instead of "Overlay Color".
In Enterprise:
- Go in Settings > Technical > Mail > Templates
- Edit a template
- In the editor, upload an image
- Choose "Upload image without optimization"
You are sent back to the app switcher.
opw-778918
When using the HTML editor, when attempting to save a syntax-invalid
XML, the error line is supposed to be displayed in red. This was not
the case anymore since saas-15. This was a simple mistake of comparison
between a stringified integer ID and its integer equivalent.
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
When double-clicking on a link/button, the link dialog is opened. The
problem was that the "btn" class is sometimes used on non-link elements.
While this should not be, the editor can easily be adapted to this.
When an element is placed multiple times in a page, it is saved only
once. Unfortunately, when a view was divided in multiple editable
parts (XML branding), only one of those parts were saved.
When editing the content of a <label/> which has XML branding (first
DOM element which is editable in its hierarchy), a <p/> element was
added inside. This behavior is there to automatically add <p/> elements
in empty editable <div/> / <section/> elements on edition. This should
however not apply on <label/> elements.
- Hide navbar divider in mobile view
- Change font to default when applying header style
- Remove form tag from media dialog search input to avoid redirection
This commit solves a bug when using custom background option: if a
custom background was selected, then hovering a non-custom background
and leaving the dropdown was selecting the non-custom background for
good instead of resetting back to the custom one. This is because the
custom background option is a non-preview one (you have to click) so
there should not be any need of resetting... except that the non-custom
background option is a preview one and messes with the same DOM
attributes as the custom background option.
qsm-odoo