When we start dragging an element with an open mega menu, the dropzones
should only appear:
- inside the mega menu: we therefore should not be able to drop a mega
menu element outside of it.
- after the clone of the element, so we can still drop it where we
started the drag (if it does not come from the mega menu).
This is well the case for normal dropzones but the grid dropzones case
was forgotten. Some "clone dropzones" are also not added for inner
contents that are in a grid mode snippet.
Steps to reproduce:
1)
- Add a mega menu with the menu editor.
- In edit mode, drop the "Text-Image" snippet and toggle the grid mode.
- Open the mega menu and start dragging one of its columns (note that it
toggles the grid mode).
=> A grid dropzone appeared in the "Text-Image" snippet, outside the
mega menu.
2)
- Drop an "Alert" snippet in "Text-Image".
- Open the mega menu.
- Start dragging the "Alert" snippet.
=> No dropzone appeared where we started the drag (so after the clone).
This commit fixes these issues. The first issue is solved by properly
filtering the `selectorGrids` when a modal or a dropdown (so the mega
menu) is open. They were already filtered for the modal case (see commit
[1] which was then refactored in [2]) but it should have been done in
`_activateInsertionZones` at the already dedicated place, instead of
before the call to this function in `_onDragAndDropStart`. This made the
siblings and children selectors filtering redundant and this code was
therefore removed.
The second issue was happening because the "clone dropzone" was only
added if there was no "closest" grid, instead of only checking the
parent. This therefore prevented it for inner contents inside grid items
instead of only for grid items. This commit fixes that. For the case
where we are dragging a grid item (still with an open mega menu), a grid
dropzone is added.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/commit/34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
task-3594979
closesodoo/odoo#146714
X-original-commit: 8eebef20de144fe223feace39546d827a0952b23
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Step to reproduce:
- Create a mega menu
- Enter edit mode and select it
- You can duplicate the top level block (but not remove it)
- If you duplicate it, you end up with a second top level block that you
can't delete ever, even by deleting inner elements one by one.
Technical details:
1. The remove button of the mega menu is already hidden thanks to commit
[1] which used the `forceNoDeleteButton` editor option introduced
with commit [2].
2. The table of content snippet also need to hide both the delete and
clone button. It was done in an "non-ideal" way with commit [3].
3. The delete button removal for table of content snippet was actually
improved to use the `forceNoDeleteButton` option of commit [2].
4. It's also commit [1] which prevent the deletion of the top level
block when deleting inner elements one by one: when the last one is
deleted, it regenerates the whole block.
This commit thus simply makes it so `forceNoDeleteButton` also hides the
clone button.
A first solution was made by introducing a new `forceNoCloneButton`
option, but there is good chances that you always want to either hide
both or show both, so merging those options for now is the simplest
solution.
It also takes the opportunity to remove the (now) useless code in the
table of content snippet.
[1]: https://github.com/odoo/odoo/commit/97810a9c40396bb27cb5779937734849d185cf1f
[2]: https://github.com/odoo/odoo/commit/7ef484377a493ebe558242480d0da6b542d6c247
[3]: https://github.com/odoo/odoo/commit/9fb2dad97cfbd412bee3cb5d1358a9835e721f60#diff-ea32a091d6b1a47aeea680fa39bbc9111260cbdaf07e9f388a9d04741806ea8fR128-R129
opw-3604033
opw-3627319
closesodoo/odoo#146745
X-original-commit: 44b006778df913b847c58b3e405d2a177fcb1a7c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the CSS properties defined by the
`o_link_in_selection` class could be applied to a link outside the
editable. In particular, the link preview in the LinkDialog widget would
display the visual indicator of a link in selection, even though it is
not editable nor selected (this happens because the link preview
contains the classes of the original link being edited).
As the styling provided by `.o_link_in_selection` is only meant to be
applied to links inside the editable, this commit makes sure the CSS
rule is specific about that.
task-3580546
closesodoo/odoo#146679
X-original-commit: b7664dc8e8a0a7909101f45d5a58473ca64d71ca
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Current behaviour before commit:
-When creating a link, the 'unlink' button is
not getting appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button is not getting disappeared
in toolbar.
-Before this commit, _updateEditorUI method is
responsible for hiding/ showing create-link
button.
Desired behaviour after commit:
-Now, When creating a link, the 'unlink' button
gets appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button gets disappeared
in toolbar.
-This commit ensures that _updateToolbar
method is responsible for hiding/ showing
of create-link and unlink button.
task-3514639
closesodoo/odoo#146680
X-original-commit: 92ca62162e85a3c617ba73eaa974d342adc3e35a
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit, pasting a URL as plain text followed by picking
"Embed Youtube Video" in the command bar failed to embed the video,
inserting the following text instead: "[object Promise]".
This happened because [1], which is the result of a forward-port, failed
to `await` the call to getYoutubeVideoElement, which is an async
function since version 15.2.
[1]: https://github.com/odoo/odoo/commit/c2f0519fec40dcf529218f39829e0a09c0f7af69
task-3611566
closesodoo/odoo#146653
X-original-commit: 4891359210e2f921dbfb6d7c870ec5cf1b60d3f5
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Since [commit 1], the columns count in the options is updated while
dragging the width handle of a column. That behavior relies on
asynchronous code which is not awaited.
This commit corrects it to be in line with the behavior of all other
options: the count is updated after releasing the drag. It also freezes
the mutex during the resize.
[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
task-3576046
closesodoo/odoo#141002
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when editing a snippet that is outdated, an alert
block is displayed above the options, warning about that. However, this
alert does not really catch the attention and it does not prevent the
user to still use the options.
This commit improves this alert block by making it cover the whole
outdated options section, to make it more visible. Moreover, it now
contains two buttons:
- one to replace the outdated snippet by its new version, and
- one to still access the options, despite the fact that they may not
work anymore.
task-3203590
closesodoo/odoo#117560
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
- Add a "Text-Image" on the website.
- Replace the image by one of your own.
- Save.
- With the html editor, remove the `mimetype` attribute, the
`data-original-src` attribute and change the `src` of the picture into
the corresponding protocol-relative one. The `src` then looks like
"//domain/web/image/...".
- Save the modifications of the html editor.
- Enter in edit mode.
- Click on the image.
-> It is now impossible to change options such as `Filter`, `Width` and
`Quality`.
Because the `data-original-src` attribute was removed from the image,
the system tries to add it back thanks to the `loadImageInfo()` logic.
Because the `src` attribute of the image is now a protocol relative url,
`new URL(src)` will raise an error and the logic will use this url as
argument for the `/web_editor/get_image_info` route. Because the url
given in argument of the rpc call is not the relative one, the system
fails to find the original attachment. The `mimetype` attribute is
therefore not added back on the image, leading to the impossibility to
change some options.
To solve the problem, this commit modifies a bit [this commit]. In order
to be robust to absolute, relative and protocol relative URLs, an URL
object is first created from the image src. The relative URL
(`.pathname`) of the URL object is then used to retrieve the original
attachment linked to the image.
Let's synthesize the different `relativeSrc` obtained with different
image src. In the following examples, "https://test.com/blog/travel-1"
will be used as `img.ownerDocument.defaultView.location.href`.
(the complete URL of the document in which the image is located).
- `src` is an absolute URL (e.g.
"https://test.com/web/image/697-d0f2aaf8/shoes.jpg"). In this case,
`relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that begins with a slash (e.g.
"/web/image/697-d0f2aaf8/shoes.jpg"). This URL represents an absolute
path starting from the root of the domain. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that does not begin with a slash (e.g.
"web/image/697-d0f2aaf8/shoes.jpg"). The interpretation of this URL
depends on the current location. In this case, `relativeSrc` =
"/blog/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a protocol relative URL (e.g.
"//test.com/web/image/697-d0f2aaf8/shoes.jpg"); there is only the
protocol missing. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
This solution takes the advantage of the second argument of the `URL()`
constructor which is used if the first parameter is a relative or
protocol relative URL and which is ignored if the first parameter is an
absolute URL.
This commit does not only modify [this commit] to handle more types of
URLs but also:
- To avoid having to use `.split()`. Indeed, `.pathname` does not
include query parameters.
- To avoid having to consider an error raised by `new URL()` as a normal
flow. Indeed, in [this commit], an error would be intercepted by the
`catch` if `src` was a relative URL. This was a legitimate flow. The
problem was that other unwanted types of src (for example protocol
relative URL) were also raising errors but were silently ignored (as
intercepted in the `catch`).
[this commit]: https://github.com/odoo/odoo/commit/89c14783846288a2de53f6258a93440e02550b13
task-3623731
closesodoo/odoo#146238
X-original-commit: 96324fe8443647a078756c98f9629af274ff38a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
[Commit 1] made sure the history worked when resizing elements by
calling `odooEditor.automaticStepUnactive()`, but applied its
counterpart `automaticStepActive()` only at the very end of the action,
leaving some `return` statements on the way that could break the flow.
This commit calls `automaticStepActive` just before leaving the listener
and moves `automaticStepUnactive` just before the first DOM
modification. It's both more logical and avoids returns pitfalls.
Note: `automaticStepActive()` makes sure modifications made on the DOM
through the browser's developer tools are tracked and can be reversed
with the undo button. Not reactivating it in time means some flows could
be broken (until another method reactivates it).
[Commit 1]: https://github.com/odoo/odoo/commit/423f4bd2a6cc47e69699d2437eaa5acda94bb98d
Related to task-3576046
closesodoo/odoo#146249
X-original-commit: b99cc41e4352d3ff9bffe7b0a5436edbef0ab01b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Current behaviour before commit:
When pressing crop button, crop widget is not getting
opened and 'connection lost' notification is appeared.
This happens because in wysiwyg.js file _rpc function
does not get the proper arguments from loadImageInfo
function.
Desired behaviour after commit:
Now, _rpc function is removed from wysiwyg.js as it
doesn't need anymore and _serviceRpc is passed directly
through the props. As result crop option works.
task-3546160
closesodoo/odoo#138482
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
If the snippet names are too long (e.g., after being translated), they
overflow and cause a horizontal scrollbar to appear on the snippet menu.
Steps to reproduce the issue:
- Set 'Finnish' as the language for the connected user in Odoo.
- Go to Website edit mode.
- Bug: Some snippet names are too long and overlfow their parent
elements.
This commit fixes this issue by adding the CSS rule 'ellipsis' to
snippet names.
task-3584011
closesodoo/odoo#145500
X-original-commit: 0ab64009ce81dc02f87c80f7de409a5dcff214c1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag and drop a 'Text-Image' snippet onto the
page.
- Select the word "Subtitle" in the title of the snippet.
- Click on the 'Animate' button in the editor toolbar.
- Bug: The 'Highlight Animated Text' icon that appeared on the right of
the title ("Inline Text") of the editor toolbar is too big.
task-3597377
closesodoo/odoo#144892
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
When a table is created the selection is set to the first `TD` of the table.
After this commit:
When a table is created the selection is set to the `P` tag inside of first `TD`
of the table.
task-3610536
closesodoo/odoo#144932
X-original-commit: 07d00347822f2d4b9fd0d315a52892030fd41693
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit:
Tab on link moves link table but the link popover stucks.
After this commit:
Tab outsided the link hides the linkpopover.
task-3389015
closesodoo/odoo#145297
X-original-commit: e9ada60cb1f6986a578e17ddce1f5ae6a6fe95dc
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit, multiple toolbar instances would be created when
switching between records via the form view pager.
This commit fixes the issue by using and properly setting up the
existing Toolbar child component, without the need to instantiate a new
one. It also removes this module's dependency on the legacy
ComponentWrapper.
task-3495685
closesodoo/odoo#144802
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
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>
Soukéina Bojabza
