Steps to reproduce the bug:
- Install the "Blogs" app and go to the "/blog" page.
- Click on "Edit" to enter edit mode.
- Go to the "Theme" tab.
- Select the 4th color from the theme colors and choose "black".
- Save the page to exit edit mode.
- Perform a search in the search bar input that yields no results, for
example: "zzz".
- Bug: The message "No results found. Please try another search." is not
visible because it is displayed in white on the white background of the
dropdown.
A previous commit [1] had already addressed the issue for the "Search"
snippet that can be dropped into a page, but this fix wasn't sufficient
to solve the problem everywhere. Indeed, the text-muted in a dropdown
should be adjusted in all cases and not just for snippets; it's a
Bootstrap issue. The text-muted color should be adapted to the
background color of the dropdown.
[1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e
task-3662985
closesodoo/odoo#158203
X-original-commit: 46fcb3712f0ba68144b03ed23f52157d4dfc789a
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Current behaviour before commit:
When trying to crop image in website, 'mousedown' and
'keydown' events are not getting caught. Due to this
- Crop is not getting closed when clicking on document
- Cropped image is not getting saved when pressing
enter
Desired behaviour after commit:
Now, events are added to the owner document of the
crop widget. As result,
- Crop gets closed when clicking anywhere in document
- Image gets saved when pressing enter.
task-3570524
closesodoo/odoo#158093
X-original-commit: afeba0d17a91d41ba2628524ccc03249835884b1
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Adnan Saiyed (adsa) <adsa@odoo.com>
When the user inserts a video with the `/video` command and provides a
link of an unlisted vimeo video, the system generates a new url based
on the options selected but omits the hash parameter granting access to
the given video. As a result, the video can not be loaded and the vimeo
`iframe` indicates that the video does not exist.
To fix the issue, we will copy the hash parameter from the original link
to the newly generated url. That way, the video will be loaded properly
and the user will be able to embed unlisted vimeo videos.
Steps to reproduce the issue:
1. Install the website app
2. Open the website builder
3. Drag and drop a text block
4. In the text block, type the `/video` command to insert a video
5. In the modal, paste the link of an unlisted video
6. The `iframe` indicates that the video does not exist
=> The system should extract the hash parameter from the provided url
and set it on the generated url. The video should then be loaded properly.
task-3697764
closesodoo/odoo#157279
X-original-commit: f72b873e58348374f3ce0e91ec5e87ed42215e55
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This adds a button to the AI Copywriter that allows the user to correct
the selected text without altering it otherwise.
task-3776377
closesodoo/odoo#156067
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
======
When you update the link button label from the sidebar it loses its
style.
Steps to reproduce the issue:
=============================
- Got to website editor
- Insert a text block
- Added a button in the text block and any label
- Click on the button to edit it from the sidebar
- Change font size or font color or any style you want
- Update the label
- The style is lost
Origin of the issue:
====================
When updating the label, we search for the first child that has that
text, but when we have `ZWS start` it will be considered as the first
child and then we update the inner text of the `a` element so we loose
the span of the text which has the custom styles.
Solution:
=========
We search for the first child which is not `ZWS`
task-3721686
closesodoo/odoo#157758
X-original-commit: 999d5787e3d8d0518692f987341dd6b298d7ffc4
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In Knowledge, embedded views anchors have a `data-behavior-props` attribute
containing information on how to render the embedded view. That attribute is
sometimes updated, and during a collaborative session, receiving such an update
as a collaborative step would trigger a full sanitization of the embedded view,
possibly discarding some transient content that could break the view, even
though it caused no security issue since it is all rendered on a per client
basis (each client fully renders its own view).
The proposed solution is to sanitize only the attribute of the node and not its
content during `_safeSetAttribute`, which is reasonable, because the node
content is already sanitized recursively for `add` mutations.
task-3060490
closesodoo/odoo#157669
X-original-commit: d9e3d7bdb6e13e6049a86ed08160daccf0fcbcc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1. Go to the website
2. Drag a snippet that contains an image
3. Select the image block
4. Go to customize the image
5. Go to transform - select crop image
6. Crop and apply changes -> Overlay is hidden
Before this commit, after cropping an image the overlay was hidden. To
make the overlay visible again, you have to click elsewhere on the
snippet and then click on the image again, because the overlay was being
hidden.
When we perform an image crop, we activate the `hide_overlay` action,
which subsequently eliminates the `o_we_overlay_preview` class. This is
due to the fact that, during the image-cropping process, the
`previewMode` is set to `false.` However, if we wish to keep the overlay
visible, We can simply avoid triggering the "hide_overlay" action.
task-3392225
closesodoo/odoo#157635
X-original-commit: 2075b4c957a8e2d03fcfd8bfab99be1e49c31ca9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Enter Website edit mode.
- Drag and drop an "Image-Text" snippet onto the page.
- Grab the right edge of the right column of the snippet and extend it
to the right until it overflows the iframe and hovers over the editor
panel.
- Release the mouse, then hover over the iframe again.
- Bug: The "mouseUp" event was not triggered, and the column resizing
still occurs.
This bug occurs because the "mouseUp" event was attached to the
<body> of the iframe and not to the window of the iframe.
Indeed, for mouse events to be triggered outside of an iframe, they need
to be attached to the iframe's window.
This fix is not necessary before the version 16.0. Before V16.0, the
page preview and the options panel shared the same window. It's only
since this commit [1], where we moved the page preview into an iframe,
that the bug occurs.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
taks-3562970
closesodoo/odoo#157627
X-original-commit: e6be732450d9ef662a48ba074e1ca1ad32e35c04
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Currently, when we color a list of links with more than three items in
the list, only the first and last links are colored.
Now when the li element is colored in a list, the font element is
created inside the link. We also make sure when the font size is defined
the font element is created inside so that the background color is
aligned with the font size
task-3677214
closesodoo/odoo#157280
X-original-commit: 4ffb15ab9d9bc7fe6d358264c1ee1ed4e48e5956
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
The goal of this commit is to update the `selectStyle` options to handle
the default CSS `"currentColor"` value.
task-3285817
Part-of: odoo/odoo#142968
After introducing the text highlights feature in [1], the text overlay
opacity was reduced for more highlight visibility on small text, leading
to a visible text overlay even on scroll.
The goal of this commit is to fix this behaviour by forcing the opacity
to 0 when the overlay should be hidden.
[1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066
task-3285817
Part-of: odoo/odoo#142968
Steps to reproduce the bug:
- Go to an event "Introduction" page
- Enter edit mode
- Click on the pre-existing "Introduction" title (note that it cannot
be removed because of the way the page is built, we might want to
improve that in master)
- Save it as a new custom snippet
- Go to your homepage
- Drop that new custom snippet that was saved
=> It cannot be removed, the rest of the content is kinda broken as
wells, etc etc.
This is because the original branding was saved with the snippet.
Indeed the event pages are made in such a way those pre-defined titles
are snippets but which are "editable root elements", i.e. elements
whose ancestors cannot be edited since themselves or their neighbors
contain dynamic elements.
opw-3633326
closesodoo/odoo#157191
X-original-commit: 356b8ce1070243ce69b5ba75d4988fcee6bc6190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to website (Homepage) > Switch to "Edit" mode.
- double-click the "Contact Us" button in the header or keep clicking it
many times > Traceback: Cannot read properties of undefined (reading
'find')...
After converting the `linktools` widget to Owl in [1], the DOM element
of the component [2] was retrieved in an async process after it was
mounted, (some legacy code can trigger the instantiation of the
`linktools` when its parent component is not in the DOM and
`this.linkComponentWrapperRef.el` won't be returned, see: `Link` >
`onMounted`).
When double-clicking the link, This implementation will lead to a race
condition where the `onWillUpdateProps()` (mainly triggered by the click
to focus the URL input...) will try to access the DOM element from [2]
before being correctly set in `onMounted()`.
The goal of this commit is to fix this behaviour by simply waiting for
`onMounted` changes to be done before doing any adaptation on the
`linktools` DOM.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
opw-3706902
closesodoo/odoo#155418
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit and most likely since commit [1], the "Open in new
window" option of link would not persist through editions.
Steps to reproduce:
- Create a link in the website builder
- Set its "Open in new window" property to true
- Save, and see that it works as expected
- Now enter edit mode again, the toggle will be off and not on as it
should be since the `target="_blank"` was correctly added.
For easy of debugging and understanding, you can just grep this line
```js
this.initialNewWindow = this.initialNewWindow || this.linkEl.target === '_blank';
```
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#
opw-3781477
closesodoo/odoo#156739
X-original-commit: 5ea2e015a8faed502c378d4e5042f8a0cf50cbf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
Ctrl+clicking on a styled link is ineffective since the target is the styled
element, which lacks an href.
After this commit:
The target should be set to the nearest `<a>` tag rather than on the styled tag.
task-3773924
closesodoo/odoo#156544
X-original-commit: baf0a2f1e77b2f7aeb7f9fd657650829e5ba5e13
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Steps to reproduce:
- Go to a website page (in "edit" mode) > Add a "Text Image" block > Add
other blocks before and after the snippet so you can scroll the page
content.
- Scroll in a way that makes only a part of the image visible.
- Select the image and click on the "Crop" button > The crop widget is
applied to the image in its current position (partially visible), which
makes it impossible to crop it correctly.
The goal of this commit is to prevent the issue described above by
simply scrolling to a position that allows to correctly edit the image
before applying the crop widget and also allowing the widget element to
scroll when trying to crop an image that overflows the current viewport.
task-3420186
closesodoo/odoo#155094
X-original-commit: 8ef34c15336c6938f40c15dbcc64c025b24d5808
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When inlining styles for e-mails, some styles could be lost if they were
defined in css but also had an inline style that started with the same
characters. For example, a node with a style attribute defining
`margin-top: 10px` and a css style defining `margin: 5px` would end up
with `margin-top: 10px` and losing the rest of the information.
opw-3650141
closesodoo/odoo#156177
X-original-commit: f2d2531125af90bd2a20e0e1a5cb5e44e7b4a02b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
=====
Clicking on hex color or rbga in colorpicker will reselect the inital
selected text and not the value if hex or rgba.
Steps to reproduce the issue:
=============================
- Create a note , type anything and apply custom color
- When clicking on the hex color code , the cursor is alwyas set back to
the text.
Origin of the issue:
====================
The behavior was introduced by
https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3
In the click listener, we always reset the comuted selection wich
reselects the original text. When clicking on empty space on the
dropdown menu, it happens too but it doesn't matter since the menu
closes anyway, but clicking on text input fields that you want to update
will be a problem since the menu doesn't close but the text get
reselected.
Solution:
=========
To overcome the problem of resetting when clicking on the dropdown, we
first check if the click is on the colorpicker or not, if Yes do nothing and
skip this.
task-3648629
closesodoo/odoo#155947
X-original-commit: 2c0a68df214f69b3d459507a6ce867620bf0513f
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behaviour before commit:
When text is selected, applying table command through
powerbox makes toolbar appear along with tablepicker.
This happens because selection is not collapsed.
Desired behaviour after commit:
Now applying table command through powerbox opens
tablepicker only.
task-3482230
closesodoo/odoo#155504
X-original-commit: d090b889f648d1f454d7af0bab828dc57b2df167
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Current behaviour before commit:
When text is selected, applying table command
through powerbox throws error.
Desired behaviour after commit:
Now when text is selected, applying table
command through powerbox creates new table
without any traceback.
task-3482230
X-original-commit: a3384f8708c07b25d092b03b671198fd6877d1d1
Part-of: odoo/odoo#155504
Steps to reproduce the bug:
- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.
task-3495241
closesodoo/odoo#134979
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.
This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).
task-3495241
Part-of: odoo/odoo#134979
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").
It mainly focuses on refining the code for better organization.
[1]: https://github.com/odoo/odoo/pull/119197
task-3495241
Part-of: odoo/odoo#134979
Commit [1] changed the behavior of `setTagName` to only carry the attributes of
paragraph related elements. Ideally, this should not carry the attributes of
`<li>` element only.
[1]: fcb3846
task-3764154
closesodoo/odoo#155448
X-original-commit: 0a47626dba4019fabaf4e399db3369b3db2e712e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Issue:
======
Invisible whitespaces at the start gets deleted by one by one with
delete forward.
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add any text
- Make sure you have an empty line before it
- Change the html of the added text and add some spaces at the start
(this is the easiest way to reproduce it)
- Go to the line before and keep deleting forward
- The invisible spaces will be deleted one by one.
Solution:
=========
When the selection is at the start of the node and it contains
whitespaces, `parentState` whill have undefined node when deleting
forward since we are at the first leaf. We need to keep deleting forward
with the text node instead of parentElement because calling delete
forward with the parent will do a 1 delete backward call from the
specified offset and it will not propagate forward anymore.
task-3629743
closesodoo/odoo#155435
X-original-commit: 6cfe30b1f194f7c53e8f91dde3251d7ba327ec56
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Delete forward on emoji dosn't work
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add an emoji and put the cursor on the left of the emoji and delete
forward
- only half of the emoji gets deleted
Solution:
=========
We need to get the correct offset and correct charsize because not all
of the items of the sliced string had char size equal to `1`. So we
slice the string and get the offset corrosponding to the target offset
and of course we need to handle the directions differently
task-3629743
X-original-commit: 80a5b41b85c7f6732407bec80c8e6117ae795333
Part-of: odoo/odoo#155435
Commit [1] introduced a way to copy translations from a (view) record to another (snippets to their real life use).
The core function that was implemented is the low level `ir.ui.view:_copy_field_terms_translations`. However, that function
did not support inputting a hierarchy of views.
Indeed, since translations are stored on the view record, each view that is part of an inheritance tree has its own translations.
So, to copy the resulting translation of an inheritance tree to a record that contains all the tree in itself, as it is the case in web_studio's ReportEditor since commit [2], there was a need for that method to support the input of a record set of potentially many records.
Hence this commit proposes to modify that method that now takes a record set of potentially many records as input and
still copies to a single record.
opw-3746922
opw-3724701
opw-3719157
[1]: cfc90c0b2f30c9e5b6aae29958997298196ee952
[2]: odoo/enterprise@b7d0d3034dclosesodoo/odoo#155346
X-original-commit: 2d58b1c65be65297cb17818c0c21dbf2b84b664b
Related: odoo/enterprise#57490
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When using the removeFormat button, the backgroundColor and
foregroundColor were not completely removed.
After this commit:
The removeFormat button will completely remove all the styles applied to it.
task-3344762
closesodoo/odoo#155146
X-original-commit: 9c4194ad3387c55d39ec7bbef1c6414893098c6e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
===================
- Open any app (sales for example)
- Toggle studio
- select reports tab
- Select any report
- Select some text and open any dropdown (font size or color)
- Click somewhere else on the document
- Select some text again
- The dropdown stayed open from the first select
Origin of the issue:
====================
Clicking somewhere on the document in studio doesn't trigger the events
`defined in bootstrap/js/dist/dropdown.js` because of the iframe.
Solution:
=========
Trigger click event on toggle button for the opened dropdown when hiding
the toolbar to close them
task-3674736
closesodoo/odoo#154969
X-original-commit: 878f3b27966a278a9332ef43e827eb2006911583
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
Articles were erroneously marked as changed,
leading to unnecessary autosaves. Part of this was
caused by the inclusion of history IDs in the
content comparison process, which differ even
without substantive content changes.
Solution:
Applied `stripHistoryIds` to the content obtained
from the WYSIWYG editor before performing the
dirty check. This ensures that comparisons focus
solely on actual content changes, eliminating
history IDs as a factor in the dirty state
determination.
opw-3707380
closesodoo/odoo#154068
Related: odoo/enterprise#56626
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Issue:
=====
When you undo a column command, you won't be able to write on that line
anymore.
Steps to reproduce the issue:
=============================
- Go knowledge
- Use column command to add columns
- Do ctrl+z
- Try to write anything
Origin of the issue:
====================
When we apply a columns operations , it will use the current block and
insert it under the first column so the `ouid` of the block will change
to the `oid` of the div (the column) so will will have 2 mutations : one
to remove the block from the root and one to add the block under the
column.
Reverting history will do the operations in reverse order, so it will
remove the block from under the column and the add it under the root but
the `block.ouid` is already set to `oid` of the column which is
different from the actual `ouid` which is `root` so adding any text to
the block will first add a textnode with `getOuid(node,true) =
block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will
mark `this._toRollBack` as true and the operation is rolled back that's
why we can't add anything anymore.
Soltuion:
=========
Mark the `ouid` of the removed elements as undefined so when we insert
them again we can recalculate it correctly.
task-3693076
closesodoo/odoo#154815
X-original-commit: 16163f135d4fc215361dddf2f4520d08a3b0ac1c
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit resolves a bug related to zero-width spaces within the inner
content of a link. The bug led to a systematic test failure in 17.0
link_tools when comparing the input value with the expected value.
The bug originated from [1] that manipulates zero-width spaces to allow
users to select the edges of the link.
Steps to reproduce:
- Navigate to the Project app and open a random task (create one if none
exists).
- Select the "Description" tab.
- Enter "/link" and press "Enter" to activate the link tools dialog box.
- In the link label field, input "The Website".
- In the URL or email field, input "localhost:8069".
- Save the changes.
- A new div is generated with the class "note-editable".
- Click on the newly created link.
- Edit the link by clicking on the edit icon in the popover.
- Direct the focus to the link label field at the end of the string "The
Website".
- Press the "Backspace" key — observe that nothing happens.
This fix is actually a complement to [2].
The test added in [3] eliminates zero-width-spaces prior to asserting
the equality of values. This was appropriately addresses and handled in
this commit.
In version 16.2 [4], they refactored and improved the handling of
zero-width spaces (ZWS). As a result, ZWS in the link are now escaped
when the selection is made, eliminating the need to filter out these
empty characters. So, I added two assertions that provide more
comprehensive test coverage. The previous test only accounted for one
way to open the LinkDialog: selecting a part of the link and clicking on
the toolbox icon. Another method is to simply click on the link. In this
case, a popover appears, allowing link editing via the edit-link icon.
In the latter case, the test fails without the fix.
In version 16.4, the link component was migrated to OWL. So the bug
isn't there anymore. The new test is kept. Note that after this commit's
merge in 16.4, it was patched with [5]. This forward-ported version
includes the patch directly.
[1]: https://github.com/odoo/odoo/commit/99bc9b115dbdfc29260b4ccdb55ffa2ed16dffb3
[2]: https://github.com/odoo/odoo/commit/71feab51f41f0658f4ad61f99386c9c6978c6025
[3]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2
[4]: https://github.com/odoo/odoo/commit/89b0ce0c74458342fea5e1b093e9383f82e2440f
[5]: https://github.com/odoo/odoo/pull/154644
runbot-44779
closesodoo/odoo#154474
X-original-commit: 9db065e75d7b31febe4a42138308b47d0fa46508
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Rodolpho Lima <rcdl@odoo.com>
Reproduction:
1. In project -> task, create a new task
2. In the description, make a table of 1 row 2 columns, type two line
long string in the second cell
3. Create a row above, type anything short, save
4. Add the portal user as follower, e.g. search user joel
5. In an incognito tab log in with portal portal, check the task and the
table is out of the field
Fix: we should not fix the columns' width when create a new head row in
the table, for extra long table, it should be scrollable
task-3559104
closesodoo/odoo#154715
X-original-commit: 997b2f2817efe06ea37e5aca278507e0ef878635
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In cases where the cursor is at the end of the current block and the next block
begins with a zero-width space, the mechanism that skips these characters while
using arrow keys should not traverse all the way to the end of the zero-width
space in the next block. Because this mechanism operates before the browser
applies its own behavior for arrow keys, potentially causing the cursor to jump
to the start of the third block when second block only contains a zero-width
space, completely bypassing the second block. Conversely true for the arrow left
keys.
This commit ensures that the navigation does not extend beyond the current block
when searching for a `newFocusNode` when moving with arrow keys near zero-width
space.
task-3653307
closesodoo/odoo#154676
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
=====
Undo of resize operation on table do 2 undos in a row.
Steps to reproduce the issue:
=============================
- Go to website editor
- Add a text block
- write `/table` to insert a table
- Resize the table
- Press `ctr+z` to undo
- The table is removed
Origin of the issue:
====================
The resize operation wasn't saved a step and is considered as draft
then it will be discarded and then the undo applied on the last saved
step that's why it appears as 2 undo in a row.
Solution:
=========
Call `historyStep` when we stop resizing.
task-3743697
closesodoo/odoo#154402
X-original-commit: 836a68e29c8fa881854b19c7489086537127d4a3
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
1. Type a backtick
2. Type "A"
3. Type a backtick
4. Hit Left Arrow key
5. Hit Right Arrow key 2x
This led to a traceback ("Cannot read properties of null (reading
'isContentEditable') at OdooEditor._onKeyDown") because using `nextLeaf`
without specifying the editable bounds returned a node that was not
within these bounds, and a subsequent call to `closestElement` on this
node returned `null` as a result.
task-3749506
closesodoo/odoo#154484
X-original-commit: ec1fe7b05e0d91605f78dd1844c7d2222671eab3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] added a rule whose intention was to unify the way our editor
labels look: capitalized. However, this is not working as intended for
translations as some languages have different rules for capitalization.
In the future, we will rely solely on the labels being written with the
intended capitalization in the first place (which is currently not the
case for dozens of English labels). As a fix, we keep the auto CSS rule
for English languages only. Hopefully, the amount of translations made
by translators being better than their auto-capitalized versions is
greater than non-capitalized English labels translated by mistake
without the auto-capitalization.
Note: this is the way python fields work too, they are not displayed
auto-capitalized in the webclient, although we want them to be.
[1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26closesodoo/odoo#153732
X-original-commit: 453b1e86840d81ffeff4d182b161b0ea50a38486
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behaviour before commit:
In v17.0 and above trying to open emoji-picker
throws traceback. This happens because not able
to find input element inside onPositioned method.
Desired behaviour after commit:
Now there is no traceback when opening emoji-picker.
task-3729610
closesodoo/odoo#153186
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
-On inserting icon in note, it replaces another icon.It occurs because
`isEmpty(block)` returns true, when block element was font-awesome, which
causes the code in `insert` method to remove current node, resulting in removal
of previous icon.
After this commit:
-Now icon is added without replacing the another icon.
task-3482264
closesodoo/odoo#152929
X-original-commit: 9a9487752131fddaf9ff163cb22226b256cef81d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Reproduction:
1. Install Sales, Email Marketing
2. Go to Email template by searching
3. Click the Sales: Send Quotation template and make a duplicate
4. Add empty lines in the template, till it almost reaches the end of
the page
5. Use slash command to add a Dynamic holder, and it’ll be positioned
below the page
Fix: compute the position by consider the height/width of the popover to
make sure it’ll be always in the page
opw-3373403
task-3442559
closesodoo/odoo#153969
X-original-commit: 583ef2441e6aa9a6d13f50991a0d1d3a54c31db1
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], it is now possible to order the columns in mobile view
independently from the desktop view. When moving a column with an arrow,
if we are in mobile view, mobile order classes are added on the columns,
which only changes the order on mobile without affecting desktop. But if
we move on desktop view, then these classes are removed.
While it works well when using the arrows, this behavior is not the same
when moving the columns with the drag and drop. This means that drag and
dropping a column
- in the same snippet does not reset the mobile order classes;
- in another snippet does not reset the classes in it and does not fill
the gap left in the previous snippet if it was ordered.
This means that in the same snippet, there can be both columns with and
without the mobile order classes. This causes some issues:
1) Removing such snippets or their ordered columns causes a traceback.
Indeed, the `onRemove` code considers that all columns have the mobile
order classes if we remove one, which is why it fails when it is not the
case.
2) The arrows on the mobile overlay are not always correct and can also
be missing, because they depend on the order classes.
3) In mobile view, changing the order of the columns adds inconsistent
mobile classes on them, because of the columns that already have one.
This commit improves the drag and drop by also taking mobile ordered
elements into account, as it is the root cause of the mentioned issues:
- When a column is moved, the order classes of all the other columns in
the snippet where it was dropped are removed (so it behaves the same way
as with the arrows).
- When moving an ordered column in another snippet, the gap it left in
its previous snippet is now filled.
This commit also fixes the issues for already dropped blocks in existing
DBs, by
- adding a check when removing to avoid the first issue;
- removing the mobile classes at the start if they are inconsistent.
[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
opw-3697962
closesodoo/odoo#152487
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Benjamin Vray