Steps to reproduce:

- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.

The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.

This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.

opw-3233360

closes odoo/odoo#117519

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, links scrolling to an anchor with a special
character did not work and displayed a traceback. The issue was that to
check that the anchor is valid, we don't need to check that the anchor
is a valid url as we have been doing since these commits [1], [2]. But
we only need to check if the jQuery selector is valid to correctly
target the element to which the page must scroll.

Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing
'oké%' wich is not valid jQuery selector. It has to be encoded to
'#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does.

We also changed the way to display a new anchor to the user in this
commit. Before, we showed the anchor unencoded in a notification and now
we show it encoded. That way, if the user copies the anchor from the
notification, it's the real anchor.

Also, this commit detect if the success URL of the redirect of a from is
the current page to perform a scroll to the anchor instead of a
redirect. To make this comparison, we needed to add the url code of the
language of the current page to the session info.

Also, before this commit, the page froze when we clicked on the "submit"
button of a form that redirected to an anchor that did not exist.

[1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420
[2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c



task-2172312

closes odoo/odoo#82059

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

There was an issue before this commit where some flags (basically all
the ones which are not tribands) would appear "broken".
This is the case for the China one where the symbol on the flag would be
squashed.
Using `object-fit` css property will keep the original flag ratio.

task-2929438

closes odoo/odoo#118903

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When the navbar hamburger type option is set to 'off-canvas', the 'call
to action' button of the 'boxed' header is located "next to" the navbar
instead of "in" the navbar as it should be.

This commit puts the 'call to action' button in the navbar when the
'off-canvas' menu is opened.

task-3063878

closes odoo/odoo#105768

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.

Note that we leave the old clickOnEdit util as it could be used in
custom codes and we don't want to break them.

task-3203820

closes odoo/odoo#116490

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When a mega menu "Sub Menus" are configured as "On Hover", it becomes
very difficult to edit its content.

This commit changes the behavior of the "On Hover" while the page is
being edited:
- it disables the hide on exit (`mouseleave`)
- it prevents the show on hover if another dropdown is already opened
- it hides the menu when the page is clicked outside of the opened menu

This commit also disables the preview of the "Show Sign In" option
which is not previewed anyway, so that it does not deselect the mega
menu when hovering the options.

task-2825376

Part-of: odoo/odoo#110258

When assigned the role of restricted editor, there are many ways to
break the web_editor when trying to do actions that should be
unavailable. There is a traceback for the following scenarios under
some circumstances (mainly because of pages without editable areas or
features without the proper access rights):

- Drag and dropping snippet when Restricted Editor.
- Clicking on product when Restricted Editor in /shop.
- Clicking on product image on specific product page.
- Clicking on user name (e.g. Marc Demo).
- Clicking on menu items or logo.
- Clicking on a blog's image in /blog.
- Clicking on a blog's image on specific blog page.
- Clicking on calendar's image in /calendar.

There is now no longer a traceback which makes the editor crash or
freeze. This mimics the behavior in other cases where the editor does
not show a traceback, but there is no message indicating that the action
is unauthorized.

When accessing a menu that cannot be edited, the "Edit the menu" button
is not shown to the restricted editor.

task-2747895
opw-3164176

closes odoo/odoo#76900

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Since [1] when a `/` was added as default text when no option is
selected in dropdown options, the selected font name is not displayed
anymore inside font options because they both rely on specifying a
`content` on the `::before` pseudo-element inside the `we-toggler`.
Because the empty value text also includes a `:empty` inside its
selector, that rule wins over the font name.

This commit makes the font name rule `!important` so that it gets
applied instead of the empty selection rule.

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



task-3256509

closes odoo/odoo#117448

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Since [1] the font family parameter was encoded twice when adding a new
google font. This causes an issue for fonts that contain spaces in their
name.

This commit removes that additional encoding and highlights the fact
that it already is an encoded parameter.

Steps to reproduce:
- Go to the Options tab while editing a website page.
- Open the Font Family dropdown.
- Select "Add a Google Font".
- In the "Google Font address" enter
`https://fonts.google.com/specimen/Open+Sans`.
- Click on "Save & Reload".

=> Field was highlighted as being wrong.

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

task-3256509

Part-of: odoo/odoo#117448

*: google_recaptcha, web_editor, website_blog, website_forum,
   website_sale_comparison, website_slides, website_twitter

This commit fixes improperly escaped query parameters across javascripts
of website-related modules.

See https://github.com/odoo/enterprise/pull/31711



closes odoo/odoo#100868

Related: odoo/enterprise#31711
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

This commit fixes several bugs with the navbar and the header templates:

- The "right" alignment options didn't work with most headers. This was
due to a missing CSS rule.

- The "right/left" alignment option was reversed with the "vertical"
header template.

- The navbar collapse style was broken with the "Hamburger Full" header
template.

- This commit hides the alignment options in cases where they have no
effect ("Hamburger Full" or "Magazine" header template + not
"off-canvas"). It also changes the options label to "Mobile Alignment"
when the alignment only impacts the mobile view (since this commit =>
[1], the "alignment" option no longer only impacts the mobile view,
depending on the templates, it can also impact the "desktop" view).

- The text section of the "Magazine" header template had no background
color (It was transparent after scrolling the page).

- The "off-canvas" navbar was not positioned correctly with several
header templates (e.g. "Boxed" header template).

[1]: https://github.com/odoo/odoo/commit/2a1aa808e939eeaa3caec6a1a82e19f023f1d010



opw-2951315

closes odoo/odoo#106764

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The public widget which is in charge of
positioning the sub-menu (`menuDirection`) could not work because the
dropdowns were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented the public
widget from aligning the sub-menu items correctly.

Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.

=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.

task-2904507

closes odoo/odoo#115153

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

Since [this commit], some JS code tries to open the sub-menus in the
right direction so that the page overflow is limited. Unfortunately,
languages that read from right to left (RTL) were not supported by this
code, which left some sub-menus of the navbar overflowing when there was
room to open them without overflowing (on the other side).
Steps to reproduce the bug:
- Have a sub-menu in the last but one position of the navbar with long
strings of characters.
- Align navbar items to the right.
- Have an RTL language installed on your website.

=> When you open the sub-menu in RTL, it opens on the wrong side and
causes an overflow of the page.

[this commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438

task-2904507

Part-of: odoo/odoo#115153

Issue:

- Go to website > edit mode > add a form
- On one of the form fields, add a placeholder > save
- Change language > translate > impossible to translate the placeholder.

The fix on [1] was added to prevent interacting with inputs in editable
zones. This prevents translating attributes on those inputs too (using
the AttributeTranslateDialog) so the goal of this commit is to add
an exception to the restriction in [1], when input attributes are
translated.

[1]: https://github.com/odoo/odoo/commit/3e598a8014966e1a07a08d53bf85050b458e05a6



task-3042522

closes odoo/odoo#106198

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce:

- Add a "Table Of Content" snippet from the website editor.
- Save > The effect on the active page item (in top menu) is removed.

Starting from [1], a `.scrollspy('dispose')` call was added to destroy
the existing ScrollSpy, and to be able to make a new call that works
correctly when the header height changed.

Since this call has no specific target as option, it will trigger the
`scrollspy._clear()` process on all `'.nav-link'` elements including
navbar items which removes the `'active'` class from current page link.

The goal of this commit is to fix this behaviour by calling the
'dispose' only when an instance of `Scrollspy` exists.

[1]: https://github.com/odoo/odoo/commit/476995ba5a1d33aa0590214609346557d1d471c0



task-3223277

closes odoo/odoo#114937

Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

*: web_editor, website_sale

Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.

We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.

This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.

During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.

[1]: https://github.com/odoo/odoo/pull/53175



task-2922635

closes odoo/odoo#98924

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

When using the 'Show on mobile' option, we can see that there is a
mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> under 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding an element in
the mobile view (for example, if it does not look good in it) has no
effect until the screen reaches 768px.

This commit increases the screen breakpoint at which the 'Show on
mobile' option is applied, that is, up to 992px instead of 768px, in
order to be consistent with the display.

task-3110770

closes odoo/odoo#109053

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit fixes two bugs with the table of content snippet:

- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.

- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.

opw-3115597

closes odoo/odoo#109927

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.

The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.

Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.

opw-3133464

closes odoo/odoo#113117

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Prior to this commit, the height of the Image Gallery snippet was set to
auto on screens smaller than 400px.

This ensures that the snippet looks the best on phones.

However, when using Bootstrap, what defines a smaller screen is not
any screen below 400px, but any screen below 768px.
This meant that the Image Gallery snippet did not look the same on an
iPhone 11 Pro max as it would on an iPhone 11 for example.

This commit fixes that by using the built-in mixin that relies on
Bootstrap's breakpoints (in this case SM).

Steps to reproduce:
- Go in edit mode and drop an "Image Gallery" snippet
- Open the dev tools and choose "iPhone 11" or 375x812
- The image gallery does not have white bands
- Change the resolution to "iPhone 11 Pro Max" or 414x896
- The image gallery has white bands / has a different layout

opw-2995100
task-2997119

closes odoo/odoo#109761

Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.

Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series

=> The matrix overflows from the editor.

There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.

As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.

task-3094162

closes odoo/odoo#107400

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.

Related PR: https://github.com/odoo/odoo/pull/110860



closes odoo/odoo#112960

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

In some cases, components had dark text over dark background (or light
text over light background) by mistake.

Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
   body color instead of the expected boxed layout color (this can also
   be seen with standard "tabs" snippets, although their body is not
   buggy in that case).

This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.

In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs. Those are for example visible on the shop main
page with the price filter enabled. With a white boxed layout and dark
background, those were broken as well.

This commit focused on fixing the only critical component: nav-tabs, for
which the fix in straightforward. CSS rules that depends on `$body-bg`
in bootstrap are less easy to fix (without duplicating their rule), are
mainly less important ones and would actually not really be possible to
fix in a fully stable way. Those will be fixed only starting from 16.0
with an entirely different fix.

[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c



opw-3151962

closes odoo/odoo#111780

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit "parallax" animation was not working in modals.

This commit adds a parameter to the animation effects to enable
animations (triggered by the scroll) in the modals.

Note that for the "Newsletter" popup we have hidden the "parallax"
options. To make them work, it would be necessary to review the
structure of the "Newsletter" popup so that the vertical scrollbar is in
the same location as the "s_popup" snippet (on the ".modal" element).

task-2971402

closes odoo/odoo#99894

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

Steps to reproduce:

    - Drop enough snippets to have a scrollbar.
    - Drop a snippet with inner content having up/down arrows (e.g.
      showcase,timeline).
    - Move inner content with the arrows.
    - => The element is correctly placed but the screen scrolled along
      with it.

This commit fixes it by preventing the page from scrolling if the
element being moved is still visible after the move. The page therefore
scrolls only if the moved element is not visible after the move.

This commit also improves page scrolling when the element is hidden at
the bottom. Before, the page scrolled to bring the moved element to the
top of the page but now, it stops scrolling as soon as the element is
fully visible.

task-2952200

closes odoo/odoo#103083

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

Commit [1] which occurred in 13.X for the upcoming release of the 14.0
version introduced a "No column" option for snippets whose only column
was removed but that we wanted having the possibility to switch to a
multi-columns layout. At the time: Title, Text and Cover snippets.

That "None" option was meant to be hidden (as it was at the time) for
other snippets already in a multi-columns layout. Indeed the "No column"
and "1 column" options are very similar: "No column" is just an
optimization for experienced users.

The problem here was that [2] broke the behavior. Indeed [1] marked the
code in charge to hide that "No column" option as "To improve" as the
system was limited to do that at the time... [2] actually improved the
system to allow hiding sub-widgets, but did not adapt [1], making the
"No column" option always visible.

While working and not harmful, that "No column" option may be confusing
as at best you don't see the difference with the "One column" option and
at worst, removing the column removes nice style that you cannot restore
by choosing a multi-column layout again afterwards.

While not entirely stable (in the end we never released a major version
where [1] was working as intended), this commit restores the idea behind
[1] anyway to avoid further confusion and tickets. Choosing "One column"
instead of "None" most of the time leads to a better UX anyway.

[1]: https://github.com/odoo/odoo/commit/b293ccc7c3c5ca9a55092afd2e4a7b88c7b93fc8
[2]: https://github.com/odoo/odoo/commit/ecefd51b63ed8c933243b4a2d26381d05ac288d2



Related to task-3106301

closes odoo/odoo#108739

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce:
-------------------
- install "website" and "sign" module;
- go to webiste (Safari) on Signatures tab;
- select a document to sign.

Issue:
------
The document is not displayed.

Cause:
------
Since [1], we try to apply modification on the `#wrapwrap` selector.
However, sometimes it does not exist.

Solution:
---------
Check if the `#wrapwrap` selector exists before applying changes.

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



opw-3102435
opw-3101909

closes odoo/odoo#108303

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce the bug:

    - In edit mode, drag and drop a popup in a page.
    - Click on the "Win $20" text in the popup to activate the overlay
    of the column.
    - Close the popup by clicking on the "s_popup_close" button.
    - Bug => the "style" tab is still activated (instead of the "blocks"
    tab).

This is actually a more general bug: when selecting text anywhere in the
page, there is no check to know if the range is editable or not.
(e.g. Selecting a link in the navbar of the "table of content" snippet
makes the toolbar appear and it is possible to change the color/size of
the selected text while these links are in a non-editable element.)

This commit adds the missing check to know if a selected range is
editable or not to show/hide the text toolbar.

This commit also removes the duplicate
"snippet_option_visibility_update" trigger_up when closing a popup with
the "close" button. It is not necessary because it is called anyway in
the "hide" event triggered by "onTargetHide".

task-3072669

closes odoo/odoo#105957

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit mitigates an issue with shape elements sometimes having tiny
spacing on their top or bottom edge.

This issue is mainly on Chrome when the user has changed the page zoom.
When the page is zoomed the elements can have a width value with a
decimal part. Because of it, the size of the SVG background images are
not correctly rounded compared to their container and therefore leaves a
visible space.

Steps to reproduce the bug:

- On Chrome, add several shapes on a website page.
- Change the zoom of the page and change the window width.
- At some points, the gap will appear.

The least bad solution we found to fix this is to ensure that the width
of the shape elements is always as close to an integer as possible.

Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]). But that wasn't enough to stop it happening. Some shapes
still need to be fixed although that will likely be done in future
versions.

[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e

task-2824607
opw-3069213
opw-3057533

Part-of: odoo/odoo#107492

Steps to reproduce the bugs:
- In edit mode, choose the "contact" header template.
- Drag and drop a table of content snippet on the page.
- Save the page.
- Click on the table of content links.
- Bug => the links are not activated correctly.

The reason of the bug was that the scrollspy offset (calculated against
the header height) was not updating when the header height changed.

We did make a new call to scrollspy at the right time but that had no
effect because we first had to destroy the existing scrollSpy to be able
to make a new call that works.

opw-2951315

closes odoo/odoo#104092

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, it was possible to resize a column so that it
overflows the right border of the row.

Steps to reproduce the bug:
  1. In website edit mode, drop a `media list` snippet in the page.
  2. Select a column.
  3. Resize the column by dragging its left side to the right to make it
  smaller.
  4. Drag its right side to make it bigger and go until the edge of the
  editor => The column overflows and ends outside of the content zone.

This commit prevents the column from overflowing when it has an offset.

task-2837361

closes odoo/odoo#96993

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

- Select the "Sidebar" header template
- Position it to the left (it's left by default)
- Select a website layout != 'full', like 'framed'

In edit mode, the menu will be floating in the middle of the screen.

Probably a bad adaption in commit [1] which refactored the code to move
the edition panel from left to right.
The rule was initially working fine for the left panel since [2].

Note that one might think that the rule should have been kept and
adapted to add the same behavior when the menu is positioned right but
this case was actually handled with [3].

[1]: https://github.com/odoo/odoo/commit/2abe8517063b2696cc89e9a453dcc3921fb3b8c7
[2]: https://github.com/odoo/odoo/commit/b30e47d81c1f71a66b1b6aa6846b52e080c25643
[3]: https://github.com/odoo/odoo/commit/f693c71b8c1b03367e00ec8f0f7854a239a9f097



closes odoo/odoo#107596

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Commit [1] improved the "sanitation" of this field for special
character. For instance, when copy pasting the following terms:

|      Input      |      Before      |       After     |
|-----------------|------------------|-----------------|
| fée d'été à 40€ |    f-e-d-t-40-   |  fee-dete-a-40  |
| Nội dung có Dấu |  n-i-dung-c-d-u  | noi-dung-co-dau |

But it actually came with a bad behavior which was not noticed: it
prevents to type `-` at the end of the input, which sounds good but is
not.
Indeed, when typing `a-word`, you will type `a` then try to type `-`
which won't work as considering a (forbidden) trailing slash, even if
you actually want to type something after.

This commit allows trailing slashes again, it's not a big deal and one
can remove it if he wants to.

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



opw-3075419

closes odoo/odoo#107610

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

For some reason, safari on mac is not showing the sidebar menu content
at all. It remains a white div without content.

Seems like a bad implementation of that browser for this case, or at
least an implementation which is not shared by all other browsers.

Note that removing `z-index`, `position:absolute` or `overflow` css
property from the `wrapwrap` will make the menu appear.
!!! Also note that having a non scrollable page (not enough content),
like an empty homepage, will make the menu appear too. !!!

As this issue is quite critical:
- All mac/safari users are not seeing your website menu..
- And the admin don't event know it most of the time (as not on mac)
And since:
- It's been going for months without someone finding a proper fix
- It's hard to investigate as devs generally don't have mac to
  investigate and have to use browserstack which is really bad for such
  work
This commit is a fix attempt using `calc` which is probably not ideal.

Step to reproduce:
- Select the sidebar header template
- Visit the website on safari
-> The menu will be invisible, like if the navbar was empty

opw-2984536
opw-2896939

closes odoo/odoo#107010

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, a deadlock caused the editor not to restart
correctly when there is an invisible element on a page. The error is
visible by following these steps:

- Edit a website page
- Click on the footer
- Toggle off the page visibility option
- Click on the navbar
- Change the template
- The editor has to restart so click on "OK"

=> The Odoo top bar stays in edit mode and the user is not able to
modify the page.

Technical information:
When entering edit mode via the URL (enable_editor) the `WebsiteNavbar`
is not yet `ReadyForActions` because it is waiting for its sub-component
`EditPageMenu` to start edit mode. Then invisible snippets options start
(so the `VisibilityPageOptionUpdate` too). But for `isShown()` to work,
the navbar must be `ReadyForActions`. This is the reason why we can't
await for `isShown()` in the start of the option, otherwise we would
have a deadlock. On one hand the `WebsiteNavbar` waiting for the
invisible snippets options to be started to be `ReadyForActions` and on
the other hand the `VisibilityPageOptionUpdate` option which needs the
`WebsiteNavbar` to be `ReadyForActions` to be started.

Related to opw-2971181

closes odoo/odoo#103783

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, the popup snippet was not displayed correctly if it
had to be displayed on all pages and the footer was a slide hover
footer. This commit just permits disabling the footer effect while the
popup is displayed.

Steps to reproduce the bug:
- Drop some block on a page
- Set the the footer Slideout Effect to "slide hover"
- Add a popup and set it to be displayed on all pages
- Save

=> The page is blocked when the popup appears.

opw-2971181

Part-of: odoo/odoo#103783
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
  exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".

Related to opw-3056683

closes odoo/odoo#106794

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide

=> There is no active indicator.

Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.

Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide

=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).

So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.

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



task-3040931
opw-3051615

closes odoo/odoo#103963

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:

(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)

- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button

=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.

opw-2967706

closes odoo/odoo#105334

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.

opw-2976261

closes odoo/odoo#105072

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>