When the user previews a background color, the background image of the
snippet is removed and re-added if the user chooses not to pick the
color. The background-image was not correctly added for carousel items.
- Handle the case where one select-class is a subset of another
select-class of the same group e.g.
<... data-select-class="hello"/>
<... data-select-class="hello world"/>
- Handle empty values <... data-select-class=""/>
Note: both cases worked but were not displaying the active checkbox
correctly in the editor UI.
The code which removed the background image of a snippet when choosing a
background color worked kinda by chance. Indeed, on the final click on
the color option, the snippet background-image was reset... to the
current background-image, which is none thanks to the color preview.
Unfortunately, in some themes, the gradient color option interferes:
the current background-image at a color choice is equal to the current
gradient, and thus, that gradient is being moved as an inline style.
The bug was introduced with https://github.com/odoo/odoo/commit/285d95e946e5a15139c961e30dbe3598e0d99f6a
(as, before, the background reset was done by simulating a click on the
'background: none' option item, which was removed).
Closes https://github.com/odoo/odoo/pull/27808
If resetting a background color was the only edition that was done on a
page and that this page was saved, the change was not properly saved
as the page was not marked as dirty.
Closes https://github.com/odoo/odoo/pull/27625
task-1879524
On Safari, when editing the template of a mail.mass_mailing,
clicking the "Read more" button (or any button that can
have a link to the website) didn't open pop up to set
the URL of the website.
PS: inspired from https://github.com/textAngular/textAngular/issues/762
opw:1889643
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes#26366
opw-1874880
closes#26582
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
If a user embeds a youtube video on his website, he has no option to remove the
suggestion of related videos at the end of playback.
Since there is no good reason to have it, we disable the related videos in all
cases.
opw 1868380
Because we converted buttons into tables so inline buttons was
breaking into multiple lines so we need to add display inline and vertical align
properties in tables.
We allowed display property from mail sensitizer whitelist.
Because in this commit https://github.com/odoo/odoo/commit/cf15030ed09f7479f5b2701ba101a5bed71f7409
we use display property for align items
Christophe Simonis