Since [1], the tooltip is not longer the jQuery-UI or Bootstrap one, but
the popover service with the Tooltip component, which does not make
changes to the editable DOM when being added or removed. This means that
switching the observer off before opening the tooltip is no longer
necessary.
[1]: https://github.com/odoo/odoo/commit/08cd27cc8ad78d2ee9ffe80ddb9e1cc50a557ee2closesodoo/odoo#141882
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Since [1], in case of import errors, the module loader waits for
`document.readyState` to be "complete" or for the "DOMContentLoaded"
event to be triggered in order to replace the DOM content by the error
report.
But, before this commit, the Wysiwyg's iframe document was opened for
writing (`document.open` and `document.write`) and was never closed. As
a result, the `readyState` would be left as `loading` and the error
import would never be displayed in case of import errors, making imports
fail silently.
This commit makes sure the iframe document's `readyState` is changed
back to "complete" after its content is written to it.
[1]: odoo/odoo@e0fdb6a0b4
task-3537756
Part-of: odoo/odoo#141882
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Before this commit, pasting html content that had been copied from the
the Editor failed to paste any content when inside an iframe.
This happened because the DOMPurify library was not configured to use
the iframe's window for Node prototypes, which led `instanceof` checks
to fail, removing nodes a result.
Additionally, commit [1] did not do the job completely: while the
document for creating the document fragment became the one received as
parameter, the DOMParser constructor remained the one from the window in
which the JS code is executed, which might be different from the
received document's window. This mismatch happens in particularly when
the editable is inside an iframe.
task-3575496
[1]: https://github.com/odoo/odoo/commit/c74d01279e49fadc5f509cfc3f6baf43d2b532d1closesodoo/odoo#144744
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
After clicking one button and then clicking another, the link label didn't
update on the link tools.
After this commit:
The link label now updates when clicking from one button to another.
task-3514717
closesodoo/odoo#144954
X-original-commit: 372c86b70b20ee3992e6376d9b6dba3c3a4b78bc
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit, when the link dialog was opened in order to edit an
existing link, the label shown in the preview section was the link's
URL instead of its label.
This happened because `_adaptPreview` (called by `start` -> `_setUrl` ->
`_onURLInput`) was called before the label input field was set (and an
empty value defaults to the link's URL).
task-3563608
closesodoo/odoo#144884
X-original-commit: 6540d5feac2fd8f4a9650288e10e3c264101fa8a
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit:
The table menu is appended directly to the body, causing issues when scrolling.
This results in the table menu toggler scrolling through the navbar, and the
position of the table menu toggler does not update on during scrolling.
After this commit:
The table UI and the editor are siblings, it eliminate's any z-index
issues. Additionally, the position of the table menu toggler is updated during
scroll.
task-3429097
closesodoo/odoo#144863
X-original-commit: f88d190a0de6328cd8dc8872be07c51f76935c3a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
When tableUiMenu is visible and we try to delete the table then tableUiMenu
stuck after table deletion.
After this commit:
Now after table deletion tableUiMenu also hide.
task-3429097
X-original-commit: 951dc35e17dfa9fbbb8906afbec82216c63e7d11
Part-of: odoo/odoo#144863
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The `noCheck` param of the `_computeSelectorFunctions` function should
permit to ignore the (not)editable environment. However, since
[this first commit] the `o_editable_media` class alter the behavior
despite the `noCheck` param which is not what we want. Even worse,
[this second commit] check the `o_not_editable` class and the
contenteditable attribute despite the `noCheck` param. This commit fixes
that by restoring the original behavior of the `noCheck` param.
[this first commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[this second commit]: https://github.com/odoo/odoo/commit/56e75ed063b0ae98b9824c0ba00633e529701242
Related to opw-3536227
X-original-commit: 19b269fb2cf7d2abc99d321ef98a1d9d19074e78
Part-of: odoo/odoo#144806
When dragging a snippet inside an iframe, after the snippet has been
dropped, all events are still being captured by the iframe.
This leads to option previews not being displayed and the user having
to click outside the iframe to be able to interact with the options.
This seems to be a bug in Firefox related to how it handles
pointerevents. This does not happen when the events are "mousedown" and
"mouseup" instead of "pointerdown" and "pointerup".
So this commit checks if we're on firefox desktop and if its the case,
uses mousedown and mouseup.
Steps to reproduce:
- On Firefox, go to the Website App and drop a banner snippet
- Click on one of the images in the snippet
- Drag the image
- Hover over the options
=> The options are not previewed
task-3607685
closesodoo/odoo#143343
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In [1], jQueryUI drag and drop was removed and replace by an in-house
solution.
This version introduced a difficulty when dragging and dropping content
when the dropzones are overlapping. This commit tries to mitigate that
by always choosing the dropzone that is the closest to the helper
element displayed when dragging.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
task-3577109
closesodoo/odoo#143167
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Reproduction:
1. Install note
2. Open an existing note and open it again in another tab
3. When you click in one tab, the cursor position in the other one is
always one step behind
Fix: separate the logic between collaboration and appliedCustomSelection
and revert the calling of getCurrentCollaborativeSelection to the place
after _computeHistorySelection
Task-3221119
closesodoo/odoo#144929
X-original-commit: 854ef7df4db577d010bed9a3561c57b3700447d8
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
The delay translation feature [1], when the website main language is not
English, is not working alongside the HTML Editor.
There seems to be multiple bugs, both in Odoo 16 and Odoo 17 following
jsonb and then delay translation.
A full investigation will need to be done (and tests written for it) for
all possible flows:
1. English DB + Website FR (only)
2. English DB + Website FR (main lang) + Website EN (translated version)
3. French DB + French Website (English is not even enabled on DB)
4. French DB + English website
5. Case 3. + Website EN (translated version)
6. Case 4. + Website FR (translated version)
Also, for each of those flows:
- both the website builder and the HTML Editor need to behaves correctly
(at least not wipe user content).
- both the Odoo records (xml views eg) and user records (new website
page eg) need to behaves correctly.
This commit, for now, disables the delay translation to restore what we
have in Odoo 16.
The whole investigation, fixes and tests will be done after this commit
in both Odoo 16 and Odoo 17.
Step to reproduce (one of the flow, which is problematic for one of our
big client to go in production):
- Have DB and admin in English
- Have FR only on the website
- Enter edit mode on a page (website builder)
- Drag & drop a snippet and save
- Open HTML Editor, add a blank line
- The page content is gone, user lost its page
------- Technical Details about above case ------------
In Odoo 16, before delay translation, in such a setup (FR only on
website), when modifying the html editor, it would have the same effect
as modifying the page content in the builder, because the English
version (not used because website only use the fr translation) would
also receive the website builder changes, both EN and FR would actually
be sync'd in DB.
For this particular case, it kind of worked, but probably not for other
cases like adding english as translation lang on the website where this
lang sync would not make sense.
This "urgent" fix/feature disabling is done because people are unable to
create or maintain website when they use the HTML Editor. Worst, they
lose all their work again and again.
Indeed, it's not yet sure how but module update also wipe user changes
in such configuration in Odoo 17.
All this is based on feedback of our "PS tech" which is unable to go in
production because of those bugs.
-------------------------------------------------------
Related to PR [2] which is the Odoo 17 forward port of commit [3]
introduced in Odoo 16.0.
[1]: https://github.com/odoo/odoo/commit/2d08f97c0778469b409fca23f2be5f5a98ce3df8
[2]: https://github.com/odoo/odoo/pull/144693
[3]: https://github.com/odoo/odoo/commit/f54aa6f58d494bca940a3e575d4092ee386d488c
task-3621753 (where the deep investigation and fixes will happen)
closesodoo/odoo#144760
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [commit 1], the tooltip that appears when a user clicks on a
snippet (instead of dragging it) is no longer displayed.
The reason is because [commit 1] replaced jQueryUI with Odoo's own code
and that triggers `preventDefault` on the `pointerdown` event which then
cancels `mousedown` and thus prevents the mousedown call back that
displays the tooltip.
To fix this, this commit replaces mousedown and mouseup events on the
`SnippetsMenu` by pointerdown and pointerup.
[commit 1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
task-3582562
closesodoo/odoo#141026
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Current behaviour:
When coloring a word multiple colors,
then wanting to re-color it a unified color,
there is a traceback.
Steps to reproduce:
1. Go to Settings
2. Click on Configure Document Layout
3. In Company Details, select a word
4. (eg: YourCompany)
5. Color half in yellow and half in red
6. (eg: Your in yellow, Company in red)
7. Then select the whole word
8. Color it in a unified color (eg: black)
9. Traceback
Cause of the issue:
range.setEnd(...endPos(last)) was throwing a warning:
During applyColor, Sanitize is called,
which merges similar nodes. (using moveNodes)
After the merge, out of n similar nodes,
only the first one is still contained in the document.
opw-3502124
closesodoo/odoo#144619
X-original-commit: 43a5aec38809f3e7e29b278704fc2143d6cc236e
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Since [1], the colorPalette component is mounted on a new App via the
attachComponent compatibility util. The new App is subject to target
validation, which fails in mass_mailing and raises a traceback.
This happens because the element for mounting the color palette is
created by the top window's document and later attached to the iframe's
DOM tree. Unfortunately this holds true for the entire sidebar is
mass_mailing.
Commit [2] apparently added some flexibility to the attachComponent
util, temporarily disabling target validation when about to mount an
App. But, due to the asynchronous nature of mounting an App, this was
not enough for the present case, as the original App.validateTarget
function is restored before it gets called when mounting the
ColorPalette.
This commit fixes this localized issued, leaving a large-scale fix, in
which the snippets menu elements are properly created by the correct
document, for a future commit on master. This will have to take into
consideration the fact that the code for the snippets menu is shared
between mass_mailing and website, and that, in the latter, the snippets
menu sits outside the iframe, thus, it is part of the top document tree.
Alternatively, the snippets menu should be refactored and converted to
owl.
task-3605859
[1]: https://github.com/odoo/odoo/commit/36061a4ab017a463c1d5bf838334cb4c0fac25ee
[2]: https://github.com/odoo/odoo/commit/6a30ab13536a2dc0a8f23df32962cd1ceec71a5dclosesodoo/odoo#143340
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Jinjiu Liu <jili@odoo.com>
Before this commit:
Pressing Enter after selecting text does not remove the selected text.
After this commit:
Now pressing enter after selecting text removes text.
task-3541359
closesodoo/odoo#144433
X-original-commit: bbd8b56ab1e91985b879c52af2a13517bf305127
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
Copy pasting table in firefox gives us traceback because the firefox does not
support :has() selector.
After this commit:
Now it will not give any traceback.
task-3591148
closesodoo/odoo#144256
X-original-commit: 224c42e4dedbb18b7f023756d652bb935d5d9829
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
This commit fixes the behavior hiding the select element when scrolling has
happened. Instead of the 'scroll' event, 'mousewheel' was used, which isn't
triggered when scrolling on a touch device.
Now, the correct event is used, and the listener is given to the actual document
element, instead of being globally listening on window (in case of iframes).
This fix is part of a bug happening in the report editor of Studio, since the
select element wouldn't be reset when scrolling, but kept visible at the same
outdated position.
ticket-3496665
closesodoo/odoo#144178
X-original-commit: f53f8b2f2cba5e586dd376ddd7ec39a16741f66a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
No test cases were there for dialog box based link creation.
After thi commit:
Added Qunit test cases for various scenarios
Cases Covered:
* Making links with hotkeys.
* Typing valid url + space should make link.
* Making link with powerbox.
* Selecting text and link button on the toolbar.
task-3087957
closesodoo/odoo#144120
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
With [commit 1], the editor toolbar was ported to OWL. One side effect
of this port is that the condition for displaying the font size dropdown
was no longer based on screen size but on the OS / Browser used. This
lead to iPads not having the font size dropdown.
This did not create a direct error on 16.4 but in 17.0, the dropdown was
changed by [commit 2] and the assumption was that it would always be
displayed.
This leads to a traceback when starting website edition on an iPad.
This commit restores the original condition for displaying the font size
dropdown which is based on screen size and not on browser.
Steps to reproduce the bug (17.0):
- Open Website on an iPad
- Start edition
=> Traceback
[commit 1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
[commit 2]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0
opw-3594634
opw-3590980
opw-3594313
opw-3594615
closesodoo/odoo#144041
X-original-commit: 6be141eab1742ad300805c6deb4805673805c7c9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It happened previously that the grid item could be broken if `top` and
`left` style properties were not set on it, which resulted in `NaN`
values being used in the grid-area computation.
This commit makes the drop more robust by obtaining their values through
the computed style instead of the style. This way these properties are
always defined.
task-3554752
closesodoo/odoo#143903
X-original-commit: 7a8fd5792f9eedfebf812b15730259de2b511a58
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Upon drop, the fix in [1] did consider invisible the blocks that were
visible within the current preview mode (mobile/desktop).
Because of this `onTargetHide` was be called instead of `onTargetShow`.
This commit changes that behavior so that the correct method remains
called according to the actual visibility, but the `DeviceVisibility`'s
`onTargetShow` is adapted to only add the override if it matches the
current preview mode.
No steps to reproduce for this first change, but third-party options
could have been impacted by it.
This commit also adds that condition on the cleanup that was added in
[2] to keep the `dataset.invisible` state consistent upon toggling the
preview mode.
Steps to reproduce this second issue:
- Drop a Columns snippet.
- Make a column visible only on mobile.
- Make another column visible only on desktop.
- Toggle preview mode several times.
=> `dataset.invisible` was set to `1` on all columns having
device-dependent visibility.
[1]: https://github.com/odoo/odoo/commit/acfca25e48ac9bc227234de860fe8128f0312ed4
[2]: https://github.com/odoo/odoo/commit/174e9fe0d8665d1a81c90a6f7bf5cc9e3361f161
task-3538535
closesodoo/odoo#143640closesodoo/odoo#143875
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In grid mode, if an image is in an image column (with the class `o_grid_
item_image`), it has the "Position" image option, allowing to select
between "cover" (= the image takes the whole grid-area, which means it
could be "cropped") and "contain" (= the image is entirely visible and
keeps its ratio in the available space). When there is a shape on the
image, this option is hidden and it is "contain" by default (or else the
shapes would be cropped). See commit [1].
Commit [2] added the "On Hover" animation option, to add hover effects
on images. In order for the effect to be applied, a shape is needed and
if no shape is specified, a dummy square shape is used instead. As there
is a shape, if it is a grid image, the "position" is forced to "contain"
(because of commit [1]).
The issue is that while it is logical for some hover effects to never be
"cover", as they could be cropped (i.e. "Dolly Zoom", "Outline", "Mirror
Blur" and any effect with a shape selected), it is not the case for the
other effects when there is no shape.
This commit improves this by allowing the "Position" option to be used
with these other hover effects when no shape is selected (so only with
the dummy square shape).
Steps to reproduce:
- In edit mode, drop the "Banner" snippet.
- Add the "Overlay" hover effect on the big image.
=> The image became "smaller" because it was forced to "contain".
[1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
task-3568406
closesodoo/odoo#141468
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since [this other commit], the `link_tools` tour is failing because the
`_syncContent` between url and link text is not working anymore. This is
due to the ZWS that are added to the link to permit the user to select
edges of the link.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
runbot-18747
closesodoo/odoo#143728
X-original-commit: 1afd1ca1539dc61ddb12345160bb82957efae143
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
- Go to website (in "Edit" mode) > Drop a new popup snippet > Make it
visible on all pages ("Show On" = "All Pages") > Save.
- Add a new language (e.g. fr) > Try to translate the page > A warning
is displayed: "Action 'get_page_option' was not able to be handled."
- Try to save > The "save" button just keeps loading and the same
warning is displayed again.
Now let's try to do the following actions [1]:
- Go to website (in "Edit" mode) > Drop a countdown snippet in the
footer > Set a conditional visibility on it (e.g. "Visibility" =
"Conditionally" = "Visible for Logged In") > Save.
- Try to translate the page > Save > We get the same error described
above.
Technical details:
Starting from [2], user has the possibility to translate invisible
blocks by allowing `_updateInvisibleDOM()` in "Translate" mode, which
makes them accessible in the edit bar.
In the case of an "All page" popup (The snippet is moved to the
`<footer/>` element to make it available on all pages...), the snippet
editor will be created with the parent's one (`<footer/>` in this
case) leading to the following behaviour when saving the page content
in "Translate" mode:
A- `cleanForSave()` called for all snippets...
B- `toggleTargetVisibility()` is then called for the `<footer/>` (which
doesn't have a `o_snippet_invisible` class).
C- `onTargetShow()` is consequently called allowing `_isShown()` to
check the footer visibility via the `get_page_option` action.
Since the navbar action widget (`ContentMenu` in this case) that handles
the action is not available in "Translate" mode, the action demand will
be aborted and we get the warning above.
Implemented solution:
- In "Edit" mode (for `s_popup` snippets):
The initial goal of this commit was to fix this behaviour by excluding
the parents when creation the `s_popup` editor in "Translate" mode.
But after some discussion, we prevent this behaviour for all `s_popup`
snippets (even in "Edit" mode) since they should not display their
parents options.
- In "Translate" mode (for all invisible snippets):
As described in [1], the issue will always occur if an invisible element
enables a parent option that needs action handers... And since we only
need to hide / display invisible elements to translate them, we also
prevent creating parents editors in "Translate" mode.
[2]: https://github.com/odoo/odoo/commit/04409af0571ed763c5712dbf857ea7dda81b2374
opw-3485565
closesodoo/odoo#143269
X-original-commit: 33e5bc36ecb5a4316ad7a61380461cb1663cb38a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
When the user creates a new article in Knowledge using a template, the
system shows a dialog indicating that there is a conflict between the
client and the server. This commit will ensure that the conflict dialog
won't show up when the document does not have any versioning yet.
Steps to reproduce the issue:
1. Go on Knowledge
2. Open the editor
3. Click on the "Browse Template" button
4. Choose a template
5. Click on the "Load Template" button
Justification
---
When the editor is started, the system generates a new snapshot with ids
generated randomly (see: constructor of `OdooEditor`, `historyReset`,
`_historyGetSnapshotStep`).
When checking if the document is "stale" (i.e: out of sync), the system
verifies the existence of a history step with the id specified in the
`data-last-history-steps` attribute of the first node of the document
(see: `_isLastDocumentStale`). If such a history step does not exist,
the client document is considered "stale" and will be discarded. The
`data-last-history-steps` attribute is set by the last writer when
saving the document.
When creating an article from a template, the server generates a new
record and copies the template's body in the article's body. The system
does not set any `data-last-history-steps` in the document. As a result,
the document will be considered "stale" when opening the article and a
conflict dialog will warn the user that the current document will be
discarded.
This commit will update the `_isLastDocumentStale` function to ensure
that a document that has not been versioned yet won't be considered as
"stale". The `data-last-history-steps` attribute will then be set when
the user opens the article and save it.
task-3587990
closesodoo/odoo#143194
X-original-commit: 69e7694580ae20bb21de1316de5aa770e7ed8eed
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Commit [1] introduces a stronger regex for url containing symbols. It did so by
using a negative lookbehind, which was not supported on some version of Safari
iOS and edge. Later commit [2] was introduced in attempt to reproduce the same
behaviour without using negative lookbehind but missed some cases such as github
compare link where the url had multiple symbols.
This commit is an attempt to reproduce the same behaviour like [1] while
improving [2].
[1]: a42a19e
[2]: ff99e45
task-3468646
closesodoo/odoo#143250
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
There were certain issues with the URL regex, wherein it failed to validate
against domain list under certain circumstances involving URLs with two dots.
for eg. this.document.anything
After this commit:
The URL regex is modified to ensure that if a URL regex does not ends with
the domains in tldWhiteList, it must start with http://, https://, www. or
if it does not start with http://, https://, www., it must end with a
domain from the tldWhiteList.
task-3468646
Part-of: odoo/odoo#143250
Before this commit:
Format and style are lost when copying content that has some style or format
applied on it.
After this commit:
Now, able to copy content with its format and style.
Task-3263360
closesodoo/odoo#142984
X-original-commit: 8083b990845eeb5b1fa6aaaa21617f16d4d5a780
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The editor has specific behaviors when it comes to icons. For instance,
marking them as `contenteditable="false"` so no text can end up into
their container element. Those behaviors were only enabled for fa icons,
this commit enables them for the new Odoo icons introduced at [1].
[1]: https://github.com/odoo/odoo/commit/546477dafab327d9990a5176bed4a9c2565eef74closesodoo/odoo#142985
X-original-commit: 4e33b5e4956da53558b0a36ae2e6da13220290ab
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There was a condition in the `isBlock` util meant to bypass
`getComputedStyle` in the case that a node was not in the DOM. Rather
than doing that however, it was bypassing it in every case where the
node was in a document that was different from that of the window.
closesodoo/odoo#142803
X-original-commit: 04a9e97603806cb21cd90d991c0f94a225c326c5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Link zws should not be applied on links that contain blocks so as to
avoid unfortunate side effects of zws on the dimensions of the link.
task-3596919
X-original-commit: 656fc7ca4d19311c679f6f3d3df6a4ea7e57c15c
Part-of: odoo/odoo#142803
Before this commit:
The Patience diff algorithm uses the text added in the `closestBlock` node to
the node where the powerbox is opened. If the user switched to a different block
using `ArrowLeft` or `ArrowRight` keys, it would result in the algorithm not
searching for the typed text in the other block.
After this commit:
The powerbox will be closed if the keyup event occurs in a different block than
the one in which the powerbox was initially opened.
task-3212128
closesodoo/odoo#141785
X-original-commit: 272614a7b668d361d6ea4177602b249608af34bb
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
Power box uses Patience diff algorithm to check the text added by the user for
search, it previously used the entire editable for differences, which caused
the issue in collaborative. When one user type something on a different node,
the change would affect the editable and be considered in diff, causing updates
in other users powerbox.
After this commit:
Instead of checking the entire editable for the diff, we now check the current
block node where the power box was opened. This prevents scenarios where other
users powerbox would update when one user would type on same block node.
task-3212128
X-original-commit: 976c10b749e59963c8a27ac4764f1746d46d5e09
Part-of: odoo/odoo#141785
Some Odoo employees reported a traceback that appeared when saving a
task in the Project app. It turned out that this was caused by an image
having the class 'o_b64_image_to_save' even though the image was not in
Base64 format. Although we couldn't reproduce the bug, we are addressing
the result (the traceback) by preventing the saving of an image having
the 'o_b64_image_to_save' class if the image is not in Base64.
See https://github.com/odoo/odoo/commit/3bbce756c69a206d07abd31059f0392c26b36096
task-3576889
closesodoo/odoo#142571
X-original-commit: 7934aefb7d52ee20941b4583cbf0a50e28c345f6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this commit], the color of the links in the backend is set to the
value of the variable `o-cc3-link`. This causes problems... Firstly,
this variable is defined in the website module, but it is used in the
web_editor module, which does not depend of website. Secondly, this
variable declared in website is made to be modified by the website
administrator via the edit panel (the theme tab). This commit corrects
this by replacing the use of this variable with a hardcoded color.
Steps to reproduce the bug fixed by this commit:
- Have website and project installed
- In the description of a project task, create a link
- Edit a website page
- Go to the theme tab
- Click on Colors Preset
- Open the 3rd preset
- Change the color for "Links" (to red for example)
=> Go back to the project task where you put a link. The link is now red
(this may require a page refresh). But the website option should not
change the links in the backend.
This commit removes the website builder related color o-cc-3-link
usage for editor links.
[this commit]: https://github.com/odoo/odoo/commit/5d598e4269431222ae28ac2196ff6f1f45466734
task-3275134
closesodoo/odoo#142542
X-original-commit: 6f10705e043115369ec581a83f65482ea83d25c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
- In edit mode, drop the "Masonry" snippet.
=> There are spaces on the left and the right of the snippet. It should
not be the case as it is supposed to take the whole space, since its
container width is full (`container-fluid` class).
This happens because since commit [1], the rule setting the `--gutter-x`
CSS variable (which manages the row margins) to 30px when the container
is full width is now overridden by the general `.o_grid_mode` rule that
sets it to 0px, making the negative margins disappear.
Indeed, in commit [1], in order to disable the grid mode when used in a
mega menu that is in an extra menu (because the layout was broken), the
CSS selector managing the `.o_grid_mode` class has been modified. This
change caused the specificity of the rule to increase (x3), which made
it override the container rule.
This commit reverts this change and disables the grid mode in the extra
menu in a better way, by adding a proper rule for this specific case.
[1]: https://github.com/odoo/odoo/commit/709bffcb6de8883b679c0fc942f45cb293621c30
task-3593697
closesodoo/odoo#142189
X-original-commit: 8381af7d9898d7502c82a6b5622b0e91734267d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In commit [1], the media dialog has been improved in order to have a
better UX when using it. However, its code is quite complex and could be
simplified.
This commit modifies again the UX of the media dialog to only consider
the addition of the "scroll button" and leaves the "Load more" button
after the attachments without making it fixed. The scroll button still
disappears once the load more button appears in the modal.
This commit also addresses the remaining review comments that were not
resolved, as it was merged in a rush.
[1]: https://github.com/odoo/odoo/commit/d1c7e371491b06176c2f5a432dccdc87b7002296
task-3580707
closesodoo/odoo#141356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
An object was defined before a conditional return statement and as a
variable rather than a constant.
closesodoo/odoo#142049
X-original-commit: d6478d9af76422eccecffb79bfd6be90cc714342
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
This commit addresses a traceback that occurs when trying to serialize a
node that has no `oid` property because it was added to the DOM while
the mutation observer was not active (eg, using `observerUnactive`).
This is the case with technical nodes added for managing the selection
around links ("link zws spans").
When serializing a node, we expect it and its descendants to have an
`oid` property so we throw an error if such is not the case. But we now
have a legitimate case where nodes have no `oid` property so this
removes the error. If the `oid` was in fact really supposed to be
defined (eg, the node we tried to serialize was the direct target of a
mutation), an error will be thrown soon enough after when trying to
access said property.
Note that other, more ad-hoc fixes specific to the link zws spans would
have been possible (and might still be useful in the future), such as:
- skipping said link zws spans when serializing
- adding a fake `oid` property to the link zws spans
task-3593081
X-original-commit: ba6a7fa4cf5ad422816e49b4d3b941297841ed3f
Part-of: odoo/odoo#142049
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
In some undeterministic circumstances the tests in
`test_wysiwyg_collaboration.js` tried to load an image with a wrong
url (`/web/image?model=res.users&field=avatar_128&id=undefined`). It
is `undefined` because in the testing context, `this.getSession().uid`
is `undefined`.
It is not necessary to load these images in these tests so this commit
prevents the loading of these images.
runbot-24600
task-3566600
closesodoo/odoo#139958
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Commit [1] implemented an approach for changing style of a list item to normal.
It no longer wrapped the content in a <p> to remove extra spacing to next list
item. Later commit [2] was introduced which did the same thing but in sanatize.
Hence the code added in commit [1] is no longer needed.
This commit removes the redundant code from `setTagName`.
[1]: 03a134c
[2]: 324e138
closesodoo/odoo#141812
X-original-commit: bd1e432dc29be0dec6e52b142d9fb712335209b6
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, some assets of the
"web_editor.wysiwyg_iframe_editor_assets" bundle could not be loaded
because of unmet dependencies.
The loading of such modules failed silently because the module loader
waits for the "DOMContentLoaded" event in order to replace the DOM's
content by the error report, and such event is not triggered by the
wysiwyg's iframe.
This commit removes unnecessary assets from the mentioned bundle and
solves the dependency errors.
closesodoo/odoo#141591
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Rodolpho Lima