Steps to reproduce the issue:
=============================
- Have 2 p elements where the last one have a link at the end of it
- Copy the 2 lines
- Paste them
- The box around the link is shown which indicates that the cursor is
  inside the link
- Try to add content
- The content is added oustide the link

Origin of the issue:
====================
When the selection have the p element and inside it there is an a
element , currentNode will be the p and not the a, but lastposition
will have the link node which is not padded with zws yet. So we put the
selection without the padding and then it's added which changes the
selection to have anchor node on the end of the ufeff charater inside
the link (`<a>&#xFEFFcontent&#xFEFF[]<a>`) which makes the selection
appears as inside the link but adding content will be after the link.

Solution:
=========
We need to pad the link with zws in case the selection we put is at the
edges of the link.

 ----------------------------------------------- 

Before:
=======
In rtl lang, the cursor gets stuck at the edge of the link using the
arrow keys.

After:
======
No the cursor moves correctly in rtl lang. We need to make `arrowLeft`
as go to next and `arrowRight` as going previous

task-4089193

Forward-Port-Of: odoo/odoo#185707

In a prior commit [1], a jQuery call was replaced with a vanilla JS implementation, inadvertently introducing an issue where unencoded URLs in background-image caused rendering or validation errors, such as "Invalid property value."

The `style.backgroundImage` property in vanilla JavaScript returns the raw value of the attribute, unlike jQuery's `.css('background-image')`, which automatically encodes URLs.

This fix ensures that URLs extracted are properly encoded using `getComputedStyle`.

Steps to reproduce:

- Install the Blog module.
- Configure your credentials in the Unsplash settings.
- Create a new post within a blog.
- Change the background of the post by searching for "electrical wire" on Unsplash. Select the first image in the results, noting that its filename contains a space.
- Click the "Add" button to set the background image.
- Save the changes.
- Observe that the background image is not applied. Inspect the style attribute of the div, and you will find: background-image: url(/unsplash/hokONTrHIAQ/electrical wire.jpg?unique=6015d8d5); This value is invalid for the background-image property due to the unencoded space in the URL.

[1]: https://github.com/odoo/odoo/commit/f9c9d6c4058086849b7e87174afd7f97d514baad

opw-4233483
opw-4271093

Forward-Port-Of: odoo/odoo#187932

Currently a parse error would arises if the user deletes the saleable product category and try to install POS

To reproduce this issue

1) Install Sale Management without a demo data
2) Delete the Saleable product category
3) Try to install POS

Error:-
```
ParseError: while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/point_of_sale_data.xml:21, somewhere inside
<record id="product_category_pos" model="product.category">
            <field name="parent_id" ref="product.product_category_1"/>
            <field name="name">PoS</field>
        </record>

```

This error is occurring because the user deleted the saleable product category, which leads to the above traceback as the saleable product category is referenced at multiple places to create master data.

https://github.com/odoo/odoo/blob/51296055790f8c6f01dfbbc82ca340756c54cdb3/addons/point_of_sale/data/point_of_sale_data.xml#L16

We can resolve this issue by preventing the user to delete the saleable product category.

sentry-6026143114

Forward-Port-Of: odoo/odoo#188788

Content of the IMP:
---

In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the  DB are not updated. This commit ensures that the quants proposed for your  move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real availability of the quant used to create it.

[FIX] stock: avoid move line reset when opening detailled ops
---

This reverts [1] commit b45e249f8f5f36cffdb1ff615953eac7bb45b995.

### Steps to reproduce:

- Enable Multi-step routes
- Create a storable product: put 5 units on shelf 1 and 5 on shelf 2
- Create and "mark as todo" a delivery order for 3 units
- Click on the detailed operation and change the reservation from shelf 1 to shelf 2 > save (the subrecord not the record)
- Reopen the details operation
#### > The records get resets in front of you

### Cause of the issue:

One of the main problems of [1] is that it modifies dirrectly the data's of the props of the component used by the X2many dialog:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L48
As such, as soon as you mount that component, you will reset the data's used by that same component. Worse, the component is doing this to itself. Hence, if you did not perform a save before opening the details operation you will reset the values to match the DB's data. Furthermore this data change modifying the props of the component we are looking at will force to reload the component with the newly hardcoded data (which explains that you see your last change resetting in front of you).

In addition, the `quant_id` field of the stock.move.line model is a very particular field as it is neither stored or computed but is used by the create and the write for the stock.move.line data's to match some of the quant informations:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L85
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L310-L311
Therefore this field will never be set on a move. line that was not  modified in JS and is not saved yet. In order to take into account  the offset between the DB Data and the data's we are setting on the form of stock move it is therefore necessary to perform an rpc to **guess**  what quant was used to create a given line. HOWEVER, as teached by the JS framework formation:
```
The first rule of customizing Odoo in JS is: do it in python
```
So that you should not do that matching in JS but rather where it belongs.

Finally, modifying the props of a component during the `onMounted` is a super hacky way to use OWL as it is the first Hook for which OWL does not destroy the component because of props inconsistency...

opw-4294650

Original issue of the reverted "FIX":
---

### Steps to reproduce

- In the setting enable Multi Step Routes
- Create a storable prodcut and put 5 units on shelf 1
- Create and Mark as Todo a delivery order for 3 units of your product
- Set the quantity of the move to 0 and save the record
- Click on the "burger list icon" of the stock move to edit the
  detailed operations and make the reservations for your 3 units
- We want to make the reservation in 2 lines targetting the same quant
- Add a new line selecting your shelf 1 quant and set the qty to 1
- Try to add a second one the quant is not proposed

### Cause of the issue:

When a quant has been selected at least once and the record is not yet saved the js data of the record contains the info of the quant used to create/update the move line because of the non stored not computed dummy field `quant_id` of the stock move. As such the quant will be considered to already having been used in this transaction and hence not available:
https://github.com/odoo/odoo/blame/54e06a1b25ed9e317e368e89979c7c77ddbffc08/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L52-L54

### Note:
The IMP fixes the original issue + more.
This reverted commit already required an other fix: Commit ea4fca8faa4ee84693e645514085a65b92364842

opw-4072541
opw-4294650
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#186400

Current behaviour:
---
When you make content of type article in eLearning, then add an animation on scroll on an element,
when you put the article in fullscreen, the animations do not trigger.

Steps to reproduce:
---
1. Go to eLearning
2. Select a course with articles
3. Click on Go to website
4. Go on the article content
5. Open the editor
6. Drag and drop the columns block at the end
7. Select "feature one" and add an animation on scroll
8. After saving, scroll, the animation works
9. Click on "Fullscreen"
10. Scroll again, animation doesn't trigger

Cause of the issue:
---
In website_slide, fullscreen mode, the right scrollable element is not `#wrapwrap`, but `.o_wslide_fs_article_content`

Note:
---
If the animation is not complete, but the page is scrolled at maximum, 
animation intensity can be lowered in the editor panel, so that the animation can finish earlier.

opw-4151770

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#184717

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in delivery in 2 steps
- Create 4 storable products: Kit 1, Kit 2, content, foo
- Create 2 boms of type kit: one for Kit 1 and one for Kit 2, both with:
  - 1 x content
- Create and confirm a sale order with two lines:
  - 1 x Kit 1
  - 1 x Kit 2
> On the associated pick, you can see 2 distinct moves: one per kit
- On the SO add a line for 1 unit of foo and save the SO
#### > On the associated pick both kit moves were merged.

### Cause of the issue:

When you add 1 unit of foo, the `_action_launch_stock_rule` will be called in order to create and confirm the associated stock moves. During the `_action_confirm` of this move a `_merge_moves` will be called to determine if the move can be merged with any other already existing one. However, this merge operation will actually be performed on each of the move present in the "candidate_move_set" which includes all the moves of the already existing picking:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1015-L1027 https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1011-L1013 This is problematic since the `disting_fields` used as a merging criterion are based solely on the records present in self and not on the candidates on which the merging might be performed: https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1021 In our case, the reason why the two kit moves where not merged the first time that they were confirmed was because the `bom_line_id` was added to the distinct fields by:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/mrp/models/stock_move.py#L605-L609 But on the action confirm of the foo move and since this move is not assocaited with a `bom_line_id` of phantom type, it will not and the two kit moves will be considered as good condidates to merge into one an other.

### Fix:

The `distinct_fields` used as a merging criterion should be based on the set of all moves that are  considered to be merged rather than to the moves that we initially wanted to merge.

opw-4337128
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#188101

Steps to reproduce the bug:
- Create a storable product “P1” and “P2”
- Create two route:
    - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action

    - route 2:
        - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action
        - rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action

- P1 -> route 1 + buy (add azure interior as vendor)
- P2 -> route 2 + buy (add azure interior as vendor)

- Create a SO: - vendor: Azure interior
    - One unit of P1 and P2

- Confirm the SO
- Go to the created PO
- Confirm the PO and go to the reception
- put in pack the products together
- Try to validate the picking

Probelm:
An User Error is triggered:
ValueError: Expected singleton: stock.location(3694, 3696)

Because we have two moves with different destination locations, and we are trying to set them in all the move lines.

opw-4291067

Forward-Port-Of: odoo/odoo#188074