Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop a "Popup" into the page.
- Drag and drop a "Text" block into the page (note that the "Text" block must be dropped after the "Popup" for the bug to occur).
- Enable the "Hide on desktop" option for the "Text" block.
- There are now 2 elements in the "Invisible Elements" list of the snippet menu. They should be ordered as follows: "Popup" and below "Text".
- Save the page.
- Enter edit mode.
- Click on "Popup" in the "Invisible Elements" list of the snippet menu.
- Bug: a traceback occurs.

When we add options for a snippet, we also add the options of its parent snippets. But for "Popup" snippets, since commit [2], we don’t want to add their parent options. So, we don’t create an editor for the parents of a "Popup."

However, when adding the "Popup" options to the snippet menu, we still check if an editor exists for its parents to decide whether to add parent options. The problem is that an editor for one of the parents might have started being created for another snippet that shares the same parent, but the creation is not finished yet, which causes the bug.

To fix this, this commit stops adding parent options for snippets that shouldn’t have a parent editor (as required by commit [2]).

Note that commit [2] was introduced in version 15, but the bug only appears in version 17.4, following commit [1], which converted the snippet menu to OWL.

[1]: https://github.com/odoo/odoo/commit/91293fe4a8125f65cd7e5f487aacbc62c35c0f74
[2]: https://github.com/odoo/odoo/commit/1acc2420d839b443d31ba63b546bcce9ea5dc237

opw-4217635
opw-4217256
opw-4190303
opw-4151866
opw-4221894
opw-4206875
opw-4127338

Steps to reproduce the bug:

- Enter edit mode.
- Drag and drop 2 "Table of Content" snippets onto the page.
- For both snippets, enable the "Hide on mobile" option.
- Save the page.
- Click on "switch to mobile view" button.
- Enter edit mode again.
- Bug: there is a traceback.

or also

- Drop a "Table of Content" snippet.
- Hide it on desktop.
- Display the snippet by clicking on it in the "Invisible Elements"
section.
- Click again on hide on desktop.

The bug occurs starting from commit [1], where a listener was added to
the scroll element in the "Table of Contents" public widget. When this
listener is removed in the destroy function, a traceback occurs if
multiple "Table of Contents" widgets are hidden. This happens because we
try to remove the listener while the widget's start function has not
finished yet, which means the listener we try to remove has not been
instantiated.

To fix this, we now await properly for the end of the start function.

[1]: https://github.com/odoo/odoo/commit/178825649fdb6fdd66ebc65732b5e903c2fca694

task-4160033
opw-4228666
opw-4226783

Since [1], when using a website boxed layout, the Bootstrap $body-bg variable was used as the color of the *box* instead of the body itself. Indeed, it made sense as default Bootstrap components started to use that $body-bg value themselves, supposing those components would be placed in the body by default, and not a colored main box.

The color of the body itself was then forced to the user-chosen Odoo color, by setting the --body-bg CSS variable Bootstrap sets up and which at the time, was only used for that.

However, since [2], the new Bootstrap version started to use that CSS variable instead of the $body-bg SCSS variable to style components. Therefore, in boxed layout, this was broken: the components used the "color behind the box" instead of the "color of the box".

Commit [3] solved a specific consequence of this issue: the tables, in boxed layouts, would use the "color behind the box" (for instance, on the shop page) breaking the design. It fixed the issue by restoring the table transparent background color as wanted (not only in those boxed layouts). But other components that use var(--body-bg) would still be broken... (un)fortunately, it seems to not be the case as we force those variables ourselves to $body-bg instead of var(--body-bg) (which will be changed in master to follow Bootstrap conventions).

[1]: https://github.com/odoo/odoo/commit/977868f5e0f50937499c89efacadf1d30ed19b5d
[2]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935
[3]: https://github.com/odoo/odoo/commit/17592b131001647cc4c8028db8c1dacb05797c0b

Related to opw-4203976

When a point of sale has more than one rescue session and the user tries to open
the rescue sessions, a traceback will appear.

Steps to reproduce the error:
- Make 2 or more rescue sessions for one point of sale
- Click on the outstanding rescue session

Traceback:
```
ValueError: Expected singleton: pos.session(22, 21)
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 40, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 459, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/point_of_sale/models/pos_config.py", line 669, in open_opened_rescue_session_form
    'res_id': self.session_ids.filtered(lambda s: s.state != 'closed' and s.rescue).id,
  File "odoo/fields.py", line 5215, in __get__
    raise ValueError("Expected singleton: %s" % record)
```

https://github.com/odoo/odoo/blob/7638f1bdd6be52554ac4266291941ef0953edfd9/addons/point_of_sale/models/pos_config.py#L669
Here, ```session_ids``` have multiple records, so when it tries to access the ```id```,
It will lead to the above traceback.

sentry-5916215733

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

### Context :
The changes introduced in https://github.com/odoo/odoo/pull/111575 seems to not have accounted for two things:

1) Running `.copy()` on the domain list object will create a shallow copy of the object. Thus, the sub-lists in the domain list are still assigned by reference. This means that when `id` gets replaced by `product_tmpl_id` (https://github.com/odoo/odoo/blob/ffcff5a784f40522ef9e3051ca3605465b99c718/addons/product/models/product_template.py#L543-L546), it actually also mutates the original `domain` variable.

2) Downstream when the conditional logic from https://github.com/odoo/odoo/pull/143543/files, i.e. https://github.com/odoo/odoo/blob/ffcff5a784f40522ef9e3051ca3605465b99c718/addons/product/models/product_template.py#L579C1-L580C93 gets triggered, it will create an invalid domain for the `product.template` model, because it tries to search based on `product_tmpl_id` instead of `id`.

In practice, when a DB is in a state that triggers the conditional logic, the user will face a non-descript traceback about an unresolved promise when trying to search for alternative products in the  product From view (“Sales” tab).
Checking the back-end, we will actually find a traceback similar to:
```
Invalid field product.template.product_tmpl_id in leaf ('product_tmpl_id', '!=', 215)
```

### Proposed solution:
Since the original intent seems to be to create a deep copy of the original domain, as to not mutate it, we explicitly import the `copy` library and run the `deepcopy` method to achieve the original intent.

OPW-4232858

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