When the floating toolbar is placed at the bottom of the selected text,
an arrow should be visible above the toolbar (pointing to the selected
text).
The CSS ruleset that makes such arrow visible was not being applied due
to an error in the CSS selector.
task-3347670
X-original-commit: 1a526b915d185e0b29bd3f9a3ff67df5178450d4
Part-of: odoo/odoo#130022
Encapsulate the `mail` ICE servers availability check in an overridable
function, since the hack does not work in a portal context, but Knowledge portal
users should be allowed to use the collaborative feature. Knowledge will
override the session check by always returning true, since mail is a dependency
of Knowledge and is therefore always installed with it.
Allow access to the edition channel for portal users.
task-3378266
X-original-commit: odoo/odoo@03e1148ac9
Part-of: odoo/odoo#128962
In Knowledge, there is a custom `KnowledgeHtmlField` which adds a menu
placeholder if the `HtmlField` value is empty. It evaluates if it is empty after
each `historyStep`.
This commit introduces new collaborative step events so that the
`KnowledgeHtmlField` is able to properly hide/show that menu even after a
collaborator made the value empty.
task-3378266
X-original-commit: odoo/odoo@b6f103bd3e
Part-of: odoo/odoo#128962
The wysiwyg component uses the ColorPalette, and gives it a callback
in props (getTemplate). This callback does an orm service call and
thus returns a promise. It is called by the ColorPalette in its
willStart, and the result (the promise) is stored in the closure of
the js module defining the ColorPalette, s.t. subsequent willStart
directly reuse the promise instead of calling getTemplate.
The problem is that the orm service (when defined via useService)
is bound to the component using it. If the component is destroyed
before the rpc returns, the promise is kept pending forever. It
might thus happen that the ColorPalette stored a promise forever
pending, leading to a screen never loading. It was for instance
the case in Invoices (list view), when you clicked on a record:
the form view might never open. In this situation, two renderings
where initiated, the first one triggered the rpc, and the second
one cancelled the first one, making the promise being pending
forever.
This commit bypasses useService to use the orm, which isn't the
best solution but it's the easiest and fastest one. Ideally, this
rpc should be done by a service, which could keep the promise in
its closure. However, a lot of test suites would need to be adapted
to make the service available for its tests.
closesodoo/odoo#129974
Signed-off-by: Géry Debongnie <ged@odoo.com>
Current behaviour before commit:
shiftTab doesn't outdent the styled text.
Desired behaviour after commit:
Now styled text gets outdent by shift + tab.
task-3283175
closesodoo/odoo#129844
X-original-commit: 1a438fa3f29794a44cda57917d2133b439c3fd0a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The DataManager is no longer used as all views and models have
been converted to wowl.
Part of task~3439226
closesodoo/odoo#129725
Related: odoo/enterprise#44611
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Steps to reproduce the bug:
- Go on a product image and replace it by a ".jpeg" (note that the
mimetype of the image is "image/webp" since [1]).
- Change the format of the image and put it to "Original". The mimetype
of the image is now "image/jpeg".
- Add a shape on the image.
- Change the format of the image.
-> None is displayed as its format.
Let's first recall that adding a shape on an image transforms its
mimetype into an "image/svg+xml" and that the `originalMimetype`
attribute is used to record its original mimetype. This is needed in
order to correctly reset the image mimetype when removing its shape.
The problem here was that the `originalMimetype` attribute was not used
correctly and that the mimetype of an image with a shape was not
correctly updated at format change.
[1]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d
task-3431015
closesodoo/odoo#129680
X-original-commit: 40811e72c50faf146ccdf9f26c332db9ebc69fa9
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Before this commit:
When attempting to open a dynamic placeholder in email marketing, a traceback
occurs.
After this commit:
Now the dynamic placeholder works properly.
Task-3373356
closesodoo/odoo#129415
X-original-commit: bb9fb402a135baf7e7b9da9bbb40888f5323ded9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
When format styles were applied to the word table, it would break table.
After this commit:
Now, when format styles are applied to a word table, the style will be applied to it
without breaking the table.
task-3165767
closesodoo/odoo#129356
X-original-commit: 0b06ba23aa111f6a85929abe8018b6b18da79873
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
We currently convert rgb colors to hexadecimal, but not rgba colors.
Unfortunately since many Bootstrap border colors are defined as rgba,
this meant that these were not properly converted for Outlook (which
doesn't support rgba).
To convert rgba while losing the transparency information we need to
"flatten" it by taking in consideration the background color.
closesodoo/odoo#129153
X-original-commit: dc56506cffa5a13508ca24018d4f0a25c5353cca
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The `font-family` style can sometimes include double quotes. This isn't
really a problem since these get escaped (`"`) but emailonacid
currently has a bug where the double quotes cause every subsequent style
to be ignored, and the rendering to be incorrect. For the sake of future
testing, this converts them to single quotes. It also removes the style
entirely from image elements since they don't make sense there.
X-original-commit: 03c7e69db63f326c7a3b3085debc5d3a5c95966d
Part-of: odoo/odoo#129153
A semi-colon unfortunately took the place of a double pipe in code that
retrieves an image's width in order to set its width attribute. This led
to some images being wrongly sized.
opw-3299392
X-original-commit: 0a21da39f05ef9ec9d202424e0e648849f44e164
Part-of: odoo/odoo#129153
Before this commit:
When changing the tag name, e.g applying a new format, the other styles
applied are removed
After this commit:
We no longer remove already applied styles of the text and only change
the tag name
Reproduction:
1. Install Email Marketing, create an email with a template
2. Drag a text block and set the background color of the whole block as
yellow
3. Set one line of the text body as Header 1, the background color is
cleared
Reason: it’s a normal result of removeFormat, it clears the background
color of the parent element and re-apply the color to the text not
selected
Fix: After checking a few most popular editors, the common behavior is
to keep the other styles applied to the text and only change the tag.
Thus this fix will remove the format removing steps. Because of this
change, the test case to check if the gradient text background color is
modified. Other specified styles are kept after the tag change.
Note: If the background color is the 5 colors at the first row, it won’t
be cleared by setting the format because the color is set as a CSS class
task-3245698
opw-3165587
Related PR/Fix:
Adding the gradient background color removal
https://github.com/odoo/odoo/pull/83065closesodoo/odoo#129285
X-original-commit: 17f90e304537e517233b8762d4fd2b7f75bfa642
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose:
--------
Currently, a crash occurs if a portal user tries to open the colorpicker
(for example in project_sharing, or in knowledge portal introduced in
16.3 [1]).
This commit fixes this by adding the group `base.group_portal` to the
groups of the colopicker template.
Task-3429053
[1] https://github.com/odoo/enterprise/commit/1badfeae8d5c93c8bba8dafd56f94f6433888590closesodoo/odoo#129274
X-original-commit: 94e3211aa84feab28ac03902d9af849967ab125c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit completes the addition of t-field with a few changes in its
behaviour in the editor:
- t-field nodes, like t-esc or t-out, are considered as unbreakable
- similarly, they are defined as 'demo data' which cannot be edited
closesodoo/odoo#128228
Related: odoo/enterprise#43978
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have the wysiwyg take an editable from an iframe. At the unmounting of the wysiwyg, save it.
Before this commit, the editable and dirty nodes were not correctly resolved as the JQuery instance
would be the one of the main document.
After this commit, we build a custom jquery function to make sure to search in the relevant document, and
be able to locate nodes even if the iframe's document is not bound to a browsing context.
Part-of: odoo/odoo#128228
Before this commit, when displaying the available conditional branches
on a node, the QWebPlugin's select element only had the name of the attribute.
This commit adds to this name, the actual condition present inside the attribute.
Part-of: odoo/odoo#128228
Before this commit, the option getContextFromParentRect was not used to compute
the position of the branching in the QwebPlugin.
Also, the Wysiwyg forced that callback in the options.
This commit fixes those two issues
Part-of: odoo/odoo#128228
Before this commit, when typing "/" inside a node that had a t-field attrbute
the OdooEditor displayed its hint in order to spawn the Powerbox.
This is not ideal as the content of a t-field is rather irrelevant.
After tis commit, a t-field node behaves like a t-out: there is no hinting inside them
Part-of: odoo/odoo#128228
*: test_website, website
Steps to reproduce the bug:
- Drag and drop a text-image snippet onto the page.
- Add a shape to the image of the snippet by selecting the shape from
the options.
- Click on the "replace" button in the options of the image.
- In the media dialog, navigate to the "icons" tab.
- Choose an icon.
- Inspect the HTML code of the icon in the DOM.
- Bug: The 'data-shape' attribute with a value is still present.
After this commit, when replacing media, the transfer of element
attributes specific to "shape" elements only occurs towards an image and
no longer towards other media (e.g. icons).
We also prevent adding shapes to images that don't support it (e.g. SVG
files). Before this commit, when replacing a .jpeg image that had
a shape with a SVG image, the shape was not removed.
This commit also adds tests to prevent these bugs from reappearing.
task-3420533
closesodoo/odoo#129079
X-original-commit: 023b0b3124a7181fdf486df8c830bb16edd10aa6
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
*: web_tour, website
When no transformation is applied on an image, changing the quality
sometimes increases its storage size.
This commit makes sure that the original image remains used if only the
image quality is modified and if this makes its storage size bigger.
Fixes#61619
task-2835144
closesodoo/odoo#103398
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit extracts the calculation of the number of bytes within a
base64 data URL to a method named `getDataURLBinarySize`.
task-2835144
Part-of: odoo/odoo#103398
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
In a subsequent commit, the ImageCropWidget will be converted into
an Owl component called ImageCrop. To match the new name, this commit
rename the file.
task-3175256
Part-of: odoo/odoo#118966
In the context of an urgent htmlField `commitChanges`, there is no time to wait
the response of `rpc` calls, therefore this commit proposes to use the same
strategy as `_toInline` for `savePendingImages` and not await the result of
the promises before a first `updateValue` if the commit is `urgent`.
This will allow to save most of the changes during a `beforeunload` scenario.
ENTERPRISE PR: https://github.com/odoo/enterprise/pull/42644
task-3372343
closesodoo/odoo#128949
X-original-commit: ba94629cb7fd1381871c37d34104f2511a4d4863
Related: odoo/enterprise#44307
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
In table selecting a list and on deletion/backspace page crashes.
After this commit:
The selected list is now deleted.
task-3383168
closesodoo/odoo#128943
X-original-commit: c7d3d247269ce27a10da39df5848cc10f9f6627b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document
(e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their
associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
Part-of: odoo/odoo#120690
This commit add a new utility method to check if the selection (current cursor
position) starts inside one of the given selectors. This method will be used,
notably, for filtering some commands inside some HTML Elements of the web
editor. Some commands should not be available within certain elements like
table, custom behaviours (knowledge app) or banners (that will be introduced in
the next commit).
Task-2782426
Part-of: odoo/odoo#120690
Before this commit, the o_not_editable class was used as a way to
dynamically set contentEditable on a node. This was little more
than a convulated way to write `node.contentEditable = false`.
Moreover, the o_editable class was not treated the same way and
did not set contentEditable to true.
This commit turns those two classes into markers for contentEditable
values in html. Once those classes are set, the contentEditable
attribute is updated accordingly. It is not updated dynamically
afterwards. For dynamically setting a node as editable or not, use
the contentEditable attribute directly.
Task-2782426
Part-of: odoo/odoo#120690
Steps to reproduce:
1. On website, drop a snippet
2. Type something, than undo it (ctrl + z or click undo button on the
sidebar)
3. On the sidebar, hover over the buttons of "Content Width" and/or
"Height" to get a preview of those actions
4. Perform a redo with ctrl + y.
Explanation:
One can only redo changes when in a state resulting from an undo, that is,
redo is the undoing of an undo. Once new changes are introduced after an
undo operation took place, a redo cannot be performed anymore.
The OdooEditor handles this at the history steps level. If there's a
a history step with state "undefined" (not resulting of undo or redo)
that is more recent than the most recent step with state "undo", a
redo is not possible.
But, before this commit, this was not handled at the current step's
mutations level. The presence of mutations in the current step did not
prevent a redo, and applying a redo on top of those changes could lead to
unexpected results, as the changes resulting from the reversion of undo
step interacted with the mutations performed subsequent to the undo
operation.
The presence of mutations in the current step when about to redo is
possible by previewing changes as described above, as they perform
DOM mutations without committing them into a history step. The same
effect can be achieved by selecting some text and hovering over the
colors of the colorpicker. Theoretically, any asynchronous compound
command (multiple calls to execCommand within historyPauseSteps/
historyUnpauseSteps) will add mutations to the current step without
committing them, while still offering the user the possibility of a redo.
This commit makes sure that mutations in the current step are treated
as an uncommitted draft and are discarded before applying a redo, mirroring
what is done for the undo operation.
task-3339304
closesodoo/odoo#128873
X-original-commit: 6ab6927c0fc4c4a1c838251953a29512dd0d3835
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: web_editor
During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.
This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.
This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.
This involves two changes:
1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.
2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.
Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied. To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.
To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.
Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.
=> The fourth image sometimes appeared below the tall image.
[1]: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198
task-2990053
X-original-commit: 9605d9ba7b26885d66e861e0e5c7dff7489031f9
Part-of: odoo/odoo#125758
Since [1] the "Images Add/Remove All" buttons are on top of the
background options in order to appear as the first option for the
"Image Wall" snippet.
This makes the JS related to the handling of the options of that
snippet created twice: once for the buttons above and once for the
options below.
Because of this, events are registered by both instances and they both
get notified on option update. Therefore, when an image is moved, it is
moved twice instead of once.
This commit differentiates both instances, and makes the one that
handles the "Add" and "Remove All" buttons be the only one that works on
the images.
In stable the differentiation is done with conditional statements.
In master the instances should be of distinct classes.
Steps to reproduce:
- Drop an "Images Wall" block.
- Switch the "Mode" option to "Grid" instead of "Masonry".
- Select the wine glass image in the third column.
- Click on "Move to previous".
=> The wine glass image ended up in the first column because it was
moved twice.
This commit also fixes a typo in the `reoder_items` name introduced
by [2].
[1]: https://github.com/odoo/odoo/commit/b6494fcf284edcddaa36b5fcfd407a6d7186fbd7
[2]: https://github.com/odoo/odoo/commit/e8713dc078b5c1799917f238a4c32b4289aceb8a
task-2990053
X-original-commit: f8724b55162b2550734dbe6e0454c406d6e4241c
Part-of: odoo/odoo#125758
When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.
This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.
Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".
=> The image wraps around all positions except the last one.
- Click repeatedly on "Move to next".
=> The image does not move anymore once it reached the last position.
[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682
task-2990053
X-original-commit: 054f480376e8d08d1582cedd6caec6455be828e2
Part-of: odoo/odoo#125758
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
Since this commit [1], when clicking on an image that is not a link and
then clicking on an image that is a link, the first image that is not a
link becomes a link.
This issue occurred because we were triggering
'activate_image_link_tool' in 'toggleLinkTools' before the options for
the selected image were ready. As a result, 'activate_image_link_tool'
was being triggered on the previous image (the one that is not a link),
causing it to become a link.
To fix this, we now only trigger 'activate_image_link_tool' if the URL
input needs to be focused (e.g., when clicking on the "edit link" button
in the image popover).
Steps to reproduce the bug:
- Drag and drop a "Columns" Snippet onto the page.
- Click on the image of the first column.
- Click on the button to create a link in the options of the image.
- Type "/" in the url input.
- Click on the image of the second column.
- Click on the image of the first column.
- Click on the image of the second column.
- Bug: a link is added on the image of the second column.
This commit also modifies the "link_tools" test to avoid this bug
reappears.
[1]: https://github.com/odoo/odoo/commit/11ee7d5520c3a14a381b3f5b973114670f1e2edb
task-3422238
closesodoo/odoo#128806
X-original-commit: fef32aa339177a2ca008ab988cb0ac0a670c110c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
On a products category page, there is an element ready to host a heading
but it's not explicitly marked as unremovable so when the user tries to
remove any snippet inside it, the heading host is removed as well. This
fixes it by using the `isUnremovable` utility function instead of simply
checking for the `oe_unremovable` class.
Steps to reproduce the issue this commit fixes:
1. Go into the website module
2. Click "Shop"
3. Click "Furnitures"
4. Click "Edit"
5. Drop a title block in "Drag building blocks here to customize the
header for "Furnitures" category."
6. Click the trash bin on your snippet to remove it.
It doesn't get removed. Well now it does.
task-3383348
closesodoo/odoo#128744
X-original-commit: d1836d2830d098e2c29cca2643b0b354859daeca
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Colors of headings are inherited between levels. (E.g. if no color is
defined for `<h4>`, it uses the color of `<h3>`)
This commit changes it so that all levels only inherit from `<h1>`.
task-3140991
closesodoo/odoo#111621
Related: odoo/design-themes#633
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, website_mass_mailing
Because the shape is now also part of the theme options for primary and
secondary button, it does not make sense to select it when the button
is either primary or secondary.
This commit makes the Shape option shown only for Custom buttons, and
therefore also nests it under the Style option.
task-3140991
Part-of: odoo/odoo#111621
This commit reorganizes the theme options to make them easier to find.
It also adds the following options:
- 'Font size' for each of the six headings
- 'Font (family)' for each of the six headings
- 'Margins' (top & bottom) for paragraph & the 6 headings
- 'Line Height' for paragraph & the 6 headings
- Harmonize buttons options with the custom button ones
task-3140991
Part-of: odoo/odoo#111621
Protect left/right arrow key handling against an empty selection (no
previous/next character to find without a selection).
Example of steps to reproduce the issue (= lose the selection while keeping the
focus):
- create such a configuration in the editable:
```html
<p [p1]><br></p>
<table>...</table>
<p [p2]><br></p>
```
- Place the cursor inside [p2] and delete the node with `CTRL + BACKSPACE`
- The cursor should have moved in the last cell of the table
- Place the cursor inside [p1]
- Start the table deletion process with `CTRL + DELETE`
- The table should be selected, as well as [p1]
- Type `DELETE` (this time without CTRL) a second time.
- The table and the paragraph are replaced by a single `<br>` node and the
selection is lost.
- Type `LEFT/RIGHT ARROW KEY`
=> Traceback
- A paragraph is inserted again when clicking in the editable afterwards
- The isolated `<br>` node stays until it is deleted by pressing on `DELETE` in
the last (reinserted) paragraph.
Typically, any other case where the selection is manipulated programatically and
not put back in the editable (be it through a bug, or because a target
selection has become obsolete and can not be found) would produce such a
taceback.
task-3425395
closesodoo/odoo#128631
X-original-commit: 2ee6e08f42f913e3102ca7340bb40b0203432b67
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Fix `deleteBackward` and `deleteForward` processes around nested editable
zones, i.e.:
```html
<div class="odoo-editor-editable" contenteditable="true">
<div class="nesting" contenteditable="false">
<div "nested" contenteditable="true">
<p>content</p>
</div>
</div>
</div>
```
- `deleteBackward`, when used:
- just after the nesting element; should remove the nesting element
- at the start of the nested element; should do nothing
- `deleteForward`, when used:
- just before the nesting element; should remove the nesting element
- at the end of the nested element; should do nothing
This commit also move some existing tests that were related to the handling of
non-editable elements in their correct `describe` section.
task-3425395
X-original-commit: a52deabecef8a5d489743b0ae07d4d32302fd76e
Part-of: odoo/odoo#128631
This commit fixes the method so that it is not allowed to probe outside the
boundaries of the `root` editable element, no matter the value of `parentLimit`.
This also allows to not specify `parentLimit` (becomes the editable element by
default).
task-3425395
X-original-commit: ffeb1abcc675dd05fb9546e39aac4498e510bbbc
Part-of: odoo/odoo#128631
The commit [b7b05a2] added a `PLACEHOLDER_TEXT` constant to consistently
change the text in `we-toggler` when no element is selected from "/" to
"None", but forgot to update one comparison.
Steps to reproduce the issue:
- Drag and drop an "Add to cart" button
=> The "Product" toggler menu shows "None" when nothing is selected.
With the updated code, it says "Choose a record...".
- Type a partial name (e.g. "desk") in the search box and press enter
=> It still shows "None".
It should select the first item available in the list. In this case with
demo data, "desk" would be "[FURN_118] Corner Desk Left Sit".
[b7b05a2]: https://github.com/odoo/odoo/commit/b7b05a2d1c1d5
task-3266751
closesodoo/odoo#128617
X-original-commit: f0f9094334e5a09b89c1fc50865c9da339d0605d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Error responses are already ignored, but connection errors would blow
up the entire thing, which breaks `test_resequence_images` (and
possibly others).
Part-of: odoo/odoo#128497
Since [1] dropped images are saved as attachments.
When such an image is a WEBP, its pre-computed resizes and conversions
to jpeg are not generated.
This commit adds the behavior of saving an `o_modified_image_to_save`
when a `o_b64_image_to_save` is a WEBP.
[1]: https://github.com/odoo/odoo/commit/3bbce756c69a206d07abd31059f0392c26b36096
task-2774352
Part-of: odoo/odoo#85494
Rodolpho Lima