The `target` attribute for a link specifies where that link should open
(for example, in a new tab). Previously, copy-pasting links in the
website editor (within text blocks for example) would remove the
`target` attribute. This implied loss of functionality.
This commit whitelists the `target` attribute to fix that behavior.
task-3184150
closesodoo/odoo#113908
X-original-commit: 1464752aca36198e5fed5dc8f5b5041244e6e4a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `isHtmlContentSupported` function incorrectly returned `false` for elements
inside `data-oe-type="html"` nodes even though those in fact do support html.
task-3184150
X-original-commit: 7d9a040fdefa527ace3150e39a03b833024b7973
Part-of: odoo/odoo#113908
Commit [1] added buttons with a `data-dependency` equal to "fake",
thinking it would hide those buttons automatically as the "fake" widget
would not exist. Somehow this got merged despite the fact that was not
working (testing probably focused on the more important things [1] was
fixing). At some point, using a fake dependency was hiding an element
but this changed one year earlier with [2].
This commit explicitly hides widgets with `data-dependency="fake"`.
[1]: https://github.com/odoo/odoo/commit/f59affcdfe9529645a02680214f3d7d96ebacf6e
[2]: https://github.com/odoo/odoo/commit/e927d1e89bc124002bb5e0b69dee711ea0d8147c
task-3208632
closesodoo/odoo#113936
X-original-commit: 7a46759a529b2d781585e0dbcb99bf7084c88007
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], an `align-items-start` class is added when going from
grid mode to normal mode in order to always have one of the four choices
of the Vertical Alignment option selected. Indeed, without this class,
none of them are chosen. However, only a few snippets have this option
and it is therefore not possible to modify this class easily in the
snippets that do not have it (except removing it from the DOM manually).
The real issue in fact comes from the computation of this option widget
state, which should select the last button (so the `align-items-stretch`
one) if no class is present, since the behaviors are equivalent in these
two situations.
This commit removes the addition of this `align-items-start` class and
fixes the `_computeWidgetState` of the Vertical Alignment option.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3142615
closesodoo/odoo#113949
X-original-commit: 75ef0d5d7ed000cf55b47bebb00cc2d0bb34b581
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since [1] it is visible that there is a race condition in the editor.
The race condition was caused by a call for an update of the option
visibility during the save, but the options may be in the destruction
process. This commit prevents the visibility of the options from being
updated when the option destruction process begins.
Before 16.0 (the merge of the frontend into the backend) the bug was
easily visible by following these steps:
- Drop 2 times the image - text block on a page
- Drop a popup block
- Save
=> During the save, a traceback occurs.
From 16.0 the race condition is more difficult to see but we still need
this fix because the problem is still there.
Note: this forward-port commit took time to get merged in master.
Meanwhile, two fixes related to it were merged in stable. The first one
already reached master a while ago ([2]) but had thus no effect as was
relying on this particular commit here. This is actually great as [2]
introduced a big mass mailing bug, fixed by the second fix which is yet
to be forward-ported to master. That one has actually been put as this
current commit's parent so that [2] is fixed before it can create the
mass mailing bug.
[1]: https://github.com/odoo/odoo/commit/686e011f9b54bcfe93cc22db24435d2ca9213664
[2]: https://github.com/odoo/odoo/commit/6bf3823c2996af4ec0534ff69471887ac43a8ddf
Related to opw-2971181
X-original-commit: 47cdb15082f774da0aa07e289361445ddc3a48f1
Part-of: odoo/odoo#107387
Co-authored-by: xO-Tx <mou@odoo.com>
Starting from [1], a `willDestroyEditors` attribute was added to prevent
race conditions caused by an update on options visibility during the
"save" (after checking the code, it seems that the issue here was caused
by the `hide.bs.modal.SnippetPopup` event which triggers the
`_onSnippetOptionVisibilityUpdate()` handler on `snippetMenu`, leading
to a traceback if editors are destroyed).
So with this fix, the visibility update will be ignored during the save
process.
[A] Note that `willDestroyEditors` is set to `true` on `cleanForSave()`
and never set to `false` after saving the content or destroying the
editors.
Another fix was added in [2] to prevent the click (before the preview
is blocked) on the page while saving, and uses the `willDestroyEditors`
attribute to ignore the click.
Now since `cleanForSave()` is called on `MassMailingHtmlField` >
`commitChanges()` and because of [A], the click will be always ignored
on this field's content.
The goal of this commit is to fix this behavior using a global
`savingContent` indicator which will be used to handle both cases
(a click on page & options visibility update) during the save.
It will be only set to `true` during the content save.
Note: the forward-port of [1] actually took too long to reach master.
Actually [2] already reached master, having no effect as relying on [1].
This commit here will actually be merged first (preventing [2] to create
the mass mailing bug when [1] reaches master). [1]'s forward-ported
version will actually be the commit following this one.
[1]: https://github.com/odoo/odoo/commit/47cdb15082f774da0aa07e289361445ddc3a48f1
[2]: https://github.com/odoo/odoo/commit/6bf3823c2996af4ec0534ff69471887ac43a8ddf
X-original-commit: b2b8590d19e07659c6ad7c3e3afba0a848b414a5
Part-of: odoo/odoo#107387
When switching records, the editable content of the previous record
is replaced by the one of the new record. Unfortunately, there was
no code that handled restoring the placeholder in case the new
content was empty after the change as this was previously only
handled in the constructor.
closesodoo/odoo#113811
X-original-commit: a3c236ef0e047127583f6565461f0b90781584e4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This event listener was added for the `historyStep` event of the editor
in [1] as a proxy for the `input` event of the editable node. This was
wrong because the `historyStep` event is also triggered at other times
than when the user makes an input.
In particular, it is called when switching records. In such case, the
new value from props can be '' which is not suitable for edition, so
it is replaced with '<p><br></p>'. But since that happens in a function
that is going to call `_historyStep` and the editing value was just
changed to something else that the value received in props, the listener
from [1] would make it dirty and thus trigger a re-render etc.
This commit fixes the issue by modifying the listener in such a way
that it listens to the proper event it was intended to target.
[1]: f56e3bca2456f04616982a9a0e77b8d4c5a0abff
X-original-commit: 384ff11f06ba86360f1993cf0c8a17c2dbaa11de
Part-of: odoo/odoo#113811
Before this commit:
Creating a new record and saving it afterwards does not show the placeholder in
the description.
After this commit:
You will see placeholders when you create a record and save it.
Task-3167136
X-original-commit: 793e48ae0478ead38ed6ac7c9a71228e2678e2c7
Part-of: odoo/odoo#113811
This removes calls to JQuery in the convert to grid tests and the
functions they test. In the process, these tests are abstracted for
better readability and maintainability.
closesodoo/odoo#113784
X-original-commit: 3eafc2d3425365bfb25b0540de95aab4e7d89ebf
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit abstracts the cell creation in the bootstrap grid inliner
tests so as to make it less wordy, easier to read, and easier to write.
X-original-commit: beceaf05f333596816623417f827ea8cdabc7097
Part-of: odoo/odoo#113784
When we convert a Bootstrap grid to a table, we sometimes need to create
filler cells to make sure the table has the same number of columns as
the grid. A mistake creeped into that process, and we were not applying
the max-width to the filler cells.
X-original-commit: a546eb1374bbe72606203ccd60322d5063a5de38
Part-of: odoo/odoo#113784
When inlining e-mails, we convert font icons to images by calling the
font_to_img route with the icon's dimensions. To get the icon's
dimensions, a call is made to `convert_inline`'s `_getWidth` and
`_getHeight` functions. These functions assume that calling
`getComputedStyle` on the icon to get its width/height will return a
value in pixels. However, this is not always the case. For example, if
the icon is in a hidden element, `getComputedStyle` can return "auto"
or whatever value is set in the icon's `style` attribute (e.g.,
"fit-content"). This commit ensures the return values of `_getWidth` and
`_getHeight` are always numbers as expected.
Doing this also reveals a false negative in the tests where the grid to
convert is not added to the DOM before calling `bootstrapToTable`. Since
`_getWidth` returned `NaN` in this case, `style.setProperty` failed
silently and no max-width was set on the cells. The tests didn't account
for the missing max-width, which now suddenly appeared with this fix
(NaN failed but 0 doesn't). This commit fixes the tests by adding the
grid to the DOM before calling `bootstrapToTable`, and adding the
expected max-width to the expected result.
X-original-commit: 73b404df9be1ba28a784711174cc19e7c599099e
Part-of: odoo/odoo#113784
When record does not contain any value for a field being checked by
`ensure_no_history_divergence`, prevent the check as there is no version
to check againts.
task-3196592
closesodoo/odoo#113767
X-original-commit: 7e32b645b28164038e13393867a79672d69e4d17
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
we don't necessarily need an error type logger here, a warning is enough.
In addition, it is reported on sentry because we receive all error type logs.
sentry-3931144637
closesodoo/odoo#113765
X-original-commit: 358a85103476d25ea507f210d0fae4eef9853669
Signed-off-by: Achraf <abz@odoo.com>
When converting the field html to owl, the mediaModalParams were
not properly assigned to wysiwygOptions.
task-3097156
closesodoo/odoo#113739
X-original-commit: 1e02313ebb98c7da4823a251a8abdd4edeece7b6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since
https://github.com/odoo/odoo/commit/1b8d663cdccced35fd294ef3481aa7ce294880f0,
in `updateValue`, the `value` and `lastValue` could have different
`data-last-history-steps` and still be the same value.
This commit fixes the method to compare the values stripped of their
history ids.
opw-3134569
closesodoo/odoo#113726
X-original-commit: 5abb2ced63caffaf528f7b71eb1c193729ecd327
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the responsive behaviour of the toolbar was a
scroll-x.
I added conditions with widget.isMobile(), to allow the layout to change
in mobile (ex: all the list options in a dropdown).
closesodoo/odoo#110161
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, there were functional issues for the floating toolbar
and design issues for the Powerbox in the web editor.
This commit fixes those issues, like alignement for the icons in the list
of the commandbar, box shadows, and the responsiveness of the floating
toolbar on mobile.
In commit [1], the toolbar dropdown had the display static added, but it
causes problems to the responsiveness.
This commit put the display back to dynamic on the dropdown and so, fixes
the dropdown not showing on mobile because of the overflow-x on auto.
The dynamic state also allows the dropdown to change direction (dropdown
to dropup) when there's not enough space for the content of the dropdown.
Would be nice to have : use display state on the all the editor
toolbars (frontend and backend) to modify the layout of the toolbar for
mobile, for a better behavior and design (ex: the different lists in a
dropdown).
For now, it's just a horizontal scroll.
[1]: 459d4e27a8
task-3087826
Part-of: odoo/odoo#110161
The presence of the history ids in the html resulted in false
positive in the `_isDirty()` comparison. This lead to unwanted
writes when switching records, even when no change were made.
task-3186072
closesodoo/odoo#113633
X-original-commit: dcd3a538ecd4d7dc35bd7de6a8e2655e7392660a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Starting from [1], the `_updateColorpicker` method was added on the
"link tools" widget to update colorpickers with the selected link colors
(and it will create the colorpicker for each CSS property on widget
`start`).
Following this update, the code on [2] and [3] added some fixes to
handle the async parts of `_updateColorpicker`. [3] was done very
recently, more than one year later after the introduction of [1]. It
turned a synchronous method into an asynchronous one (rightfully
considering the async calls to `_updateColorpicker` that were inside).
As a fix, this commit will try to re-made it a synchronous method, and
other parts related to `_updateColorpicker` too.
The goal of this commit is to separate the link tools colorpicker
"creation" code (`_addColorPicker` now) from colorpicker's "update"
code. These changes are supposed to fix a race condition issue that
appeared on 16.0, but since the code is the same on 15.0 and subject to
the same issues, we target 15.0 with this fix. Hopefully, this prepares
for an easier refactoring in master.
[1]: https://github.com/odoo/odoo/commit/26d37812f0217ae913c8ddf761bcb26b5c44bff5
[2]: https://github.com/odoo/odoo/pull/78301/commits/6f1a6b76642db2e4f81cf3474ad0ec745a4bb3c9
[3]: https://github.com/odoo/odoo/commit/d15fdca644ef9ed1dfb011d3790f403e0157f55b
runbot-5753
closesodoo/odoo#113510
X-original-commit: 2d4a3efe0d7c9618c388575b4bb652a26913fe68
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Using a lazy `?` quantifier lead to poor matching performances and
was not needed technically.
Using `*` instead of `+` lead to a lot of false positives when trying
to write records with an empty value for `data-last-history-steps`.
It is currently unclear how to reach such a case but in the meantime
it is better to allow people to write the record as such rather than
being completely locked with no possibility of saving.
closesodoo/odoo#113540
X-original-commit: 0a370758972e6a0c399471f9982f3898da92ef68
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Olivier Dony <odo@openerp.com>
Because the `selectionchange` event is async, the selection can
be null if the node has been removed between the moment the
selection was moved and the moment the event is triggered.
X-original-commit: 3232edb1ccb196c992f75858fe81d08a5af58ab9
Part-of: odoo/odoo#113540
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the website editor, a traceback error occurs when clicking on the
main element since the commit [1]. This is caused by the function
'_handleSelectionInTable' calling 'selection.getRangeAt(0)' without
checking if there is at least one range in the selection.
Steps to reproduce the bug:
- Open the website editor and drop a text snippet onto the page.
- Click on the snippet to activate it.
- Click on the empty area below the snippet, which corresponds to
the <main> element.
- A traceback error will appear (if it does not appear, repeat the
first three steps multiple times).
[1]: https://github.com/odoo/odoo/commit/d977bd64fe88c059c915f9eb0f8029cde65b216a
task-3196722
closesodoo/odoo#113383
X-original-commit: 6e79728c7e812458709d3a60ba37dc4c578905b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
Following this flow on the Media Dialog:
- Type "hell"
- Wait a few ms so that the RPC to search images starts
- Type "o"
- The RPC of before finishes, the o is removed and no new search is done
Before this commit, the search input value of the SearchMedia component
was coming from a "needle" props. This needle prop was a state on the
parent component (FileSelector), set through a debounced handler.
This is not a good design:
- Type "hell": after 1000ms, the debounced handler will be executed with
the value "hell"
- While the handler is executing: type "o"
- When the handler finishes, it has set the needle state value to "hell"
on the parent. This will rerender the SearchMedia with "hell" as a
needle prop, and the "hello" input will be replaced with "hell".
Instead of doing that, the SearchMedia component should have its own
input state, which models the input element.
On that state, we use an effect to call the debounced "search" callback.
This way, the SearchMedia is less dependent on its parent: it only
rerenders when its input element changes.
Additionally, the fetch results are only used if they are the ones from
the last call to `search`.
Dedicated `KeepLast` instances are used for attachments, media library
and unsplash.
task-3060679
closesodoo/odoo#113188
X-original-commit: 08859ca7939454303e34dc39c831ac8f75773c3d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Commit[1] intended to change the color of links in the editor to make them more
visible by making them a slightly lighter color. However, it did so in a way
that also applied to button links, which already had different colors. In the
case of primary buttons, it actually made the links less readable as a result.
This commit excludes buttons from the original css rule so that they keep their
special style while still maintaining the intent of the original commit.
[1]: 47c73c7213
task-3131568
closesodoo/odoo#113141
X-original-commit: a40bca916ac17338d82c52afd7c0eedd96d4a49d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, creating a link through the link tool made two
steps instead of one.
task-3147819
closesodoo/odoo#113135
X-original-commit: d967c21b6abdccd45f3c767925de29e874497dd4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when discarding a link in linkDialog, there was a
link and a history step that were created. We now properly come
back to the state of the editor before the linkDialog was opened.
task-3147819
X-original-commit: 79205c8df555d7194d4a8a0ad4f04a9f7dc7f535
Part-of: odoo/odoo#113135
When clicking in a link in the forum, the link dialog was opened.
This is wrong as there the link popover is shown and to open the link
dialog, we must click on the button in the link popover.
task-3147819
X-original-commit: 5c5aa21dffe3691547766cf1f16065ae74c41f07
Part-of: odoo/odoo#113135
Using the web_editor html field in the Record component causes crashes.
Why does this happen?
The fields used in the Record component do not always have modifiers.
Solution:
Use the isReadonly function of the record to know if the field is
readonly or not.
closesodoo/odoo#113072
X-original-commit: 5354321877b65d577c419255ce43806f648e1708
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] removed the protection around the call to setDirty because setDirty
is always defined when the field is initialized through the standard field.js
mechanism. However, in todo_list.js in hr_payroll, the html field is called
without going through that mechanism, resulting in the prop being missing and the
call to fail with a traceback.
This could be fixed by adding the missing prop to todo_list.js, but other people
are likely to do the same mistake in the future so adding a default of our own is
probably better to avoid future similar bugs.
[1]: https://github.com/odoo/odoo/commit/f56e3bca2456f04616982a9a0e77b8d4c5a0abffclosesodoo/odoo#112994
X-original-commit: a6043b3aa290d6cecaabc02995e490f44cbd6ce2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The default font size of the frontend is 16 so the `default` option
in the font size dropdown was supposed to be enough for this use case.
However, this is not true in the context of website_blog where the
default font size of blog content is not 16. This is not a problem
because if the user does not like the default blog font size then
they can change it using the font dropdown... except they have no
way to select 16 for a size and `default` doesn't mean 16 in blog.
This commit adds an explicit entry for 16 in the font size dropdown.
opw-3110711
closesodoo/odoo#113011
X-original-commit: a35679d5a30e3931216c65ff4ea896e507ba4cf1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
To reproduce the issue:
- Website > Add menu items to activate the "+" dropdown.
- Edit mode > The top menu disappears.
On `_activateContenteditable()`, The `initAutoMoreMenu` > `_adapt()`
mutations (changes to move the overflowing menu items to a "+" dropdown)
are recorded and rollbacked by the editor, leading to reset the top menu
to the step before removing the `.o_menu_loading` class.
Recording the `initAutoMoreMenu` mutations leads to some other issues:
On edit mode (without overflowing items):
- Website > Edit mode > The editor starts (before any updates) with an
extra "history step".
- Undo > The top menu disappears.
On edit mode (with "Mega Menu" items):
- Website > Edit mode > Edit text in a "Mega Menu" item > The top menu
disappears.
The goal of this commit is to fix this behaviour using the
`renderingClasses` filter (added in [1]) to prevent the `o_menu_loading`
class from being taken into account in the `filterMutationRecords()`.
[1]: The https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
opw-3146873
closesodoo/odoo#113016
X-original-commit: 96c9ebd26aabc3f99acf5d586746b05db7cf4953
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a `we-select` has no elements, it is drawn as a flat line.
This commit puts a "/" in its toggler content. This character is the
same one as the one that is displayed if the selected value is not one
of the available values.
Steps to reproduce:
- Delete all `website.snippet.filter`
- In debug mode, drop a "Dynamic Snippet" in a website page
- Select it
=> The "Filter" option was displayed as a flat line.
opw-3166634
closesodoo/odoo#112932
X-original-commit: dc6ff20386567abbabcb2d35388a3dc8995cab28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This function is deprecated as its behaviour is closer to "debounce".
Furthermore, it is not covered by any tests.
Only one usage has been found in the code base:
- the VideoSelector component from web_editor
This usage has been replaced by the "debounce" timing utility,
which is appropriate considering what the code tries to do.
Part-of: odoo/odoo#112913
This commit improves the ListUserValueWidget to scoll to the new element
when the user adds a new element.
task-2601533
closesodoo/odoo#81241
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Changing numeric values using the keyboard arrows did not work on some
fields. This commit solves this problem by adding the necessary
attributes to the numeric (we-)inputs.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's lists. The
fields that make up the list can trigger a preview and it is possible to
switch from one field to another using the keyboard. Note that the
social media we-list must render at each blur of one of its inputs, so
this we-list does not allow to switch from one input to another with the
keyboard.
As the we-list events changed, the social media block tests had to be
slightly modified to take these changes into account.
task-2601533
Part-of: odoo/odoo#81241
Before this commit, if there were no selection in
`_handleSelectionInTable` because the document was removed (in case the
document was in a removed iframe), the method would crash.
task-3052658
closesodoo/odoo#112908
X-original-commit: 8e23a4191730d5512c9de81c23f8e4e88e99ddb1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, some operation (eg. move node, duplicate or remove a
snippet from the snippetMenu) in the snippetMenu sidebar did not
trigger the mass mailing commit changes and therefore if no selection
was made in the document followed by a blur was made, no changes could
be recorded and saved by the owl form component.
task-3052658
X-original-commit: 8bd8db97ee0d7774e5aa0495b9a5cc7d695fca67
Part-of: odoo/odoo#112908
When the debug assets option is not activated, the assets are rendered
with a space being trimmed from a string notation using backtick.
This fix, uses the single quote notation to avoid this issue in
`wysiwyg_iframe`. Without that fix, the structure of the dom is wrong
and causes css rules to not be applied.
task-3100202
X-original-commit: c54fcf21aecccac20b2c1d781132ed67df6c20a7
Part-of: odoo/odoo#112908
Before this commit, the sidebar visibility was toggled with a css
transition, each time a change was made in the html_field.
Additionally, the transition was not working properly when opening
a mailing. Because this transition was made for website and this code
is no longer being used in website and is not usefull for mass mailing
we can remove it.
task-3100202
X-original-commit: 21056444562e530fb811095b4805345709295ca3
Part-of: odoo/odoo#112908
Stanislas Gueniffey