After commit [1], the check that the target url is different from
the current page's url has been removed thus leading to error that anchor
link always scroll down to element that have data-anchor enabled.

Steps to reproduce (the easiest way):
- Install Website Blog
- Turn on customize comment on post
- Go incognito then access any blog post, scroll down and click the
`Sign in to leave a comment` button
- Holy, the page scrolls down to the discussion section but doesn't go
to the login page

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



closes odoo/odoo#135620

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

Steps to reproduce the bug:

- Website application
- Go to Website
- Go to menu "Pages"
- Click on "Edit Menu"
- Click on "Add Menu Item"
- Bug: This leads to a traceback.

This bug was introduced by the commit [1], where we do a
"querySelectorAll" on the anchor selector element, which doesn't
actually exist in the "Add Menu Item" dialog. The code related to adding
an anchor shouldn't be executed in this modal. This was changed in
versions higher than 14, where we separated the code used in the
"Add Menu Item" dialog from the code used for editing links in edit
mode.

In this commit, we fix this issue minimally by adding a "return"
statement if the anchor selector element doesn't exist.

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



opw-3422898

closes odoo/odoo#129710

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

Steps to reproduce the bugs:

- Add a banner on the homepage
- Click on the "create a link to target this section" button.
- Edit the anchor name to "bannerAnchor".
- Drop the image-text snippet.
- Double click on the button inside the snippet.
- Choose the homepage as the URL ("/")
- Open the "Page Anchor" select, choose "#bannerAnchor"
- Validate the changes.
- Double Click on the snippet button again.
- First bug: The URL properly shows "/#bannerAnchor" but the page anchor
select does not show anything.
- Open the page anchor select again.
- Second Bug: the "bannerAnchor" option does not appear as a choice.

This commit fixes the two bugs described above.

task-3378864

closes odoo/odoo#126393

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

Prior to this commit, when using the "Slide Hover" reveal effect on the
footer, Safari would glitch it scrolls and could result in unreadable
content.

This commit fixes this by a weird hack that seems to work. Adding an
element with a background-image and a background-attachment set to
fixed seems to resolve the issue.

task-3302302

closes odoo/odoo#122029

Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>

When a sub-menu needs to be opened in the navbar, it sometimes gets
nested within the navbar itself, making a vertical scrollbar appear
instead of floating outside the navbar, above the top of the page.
This happens if the navbar was opened in small screen sizes using the
hamburger icon, then, after a rotation, the navbar is turned into its
fully expanded version.

This commit hides the hamburger menu if the collapse toggler becomes
`display: none`.

Steps to reproduce:
- Add a sub-menu nested under the "Home" menu.
- Open the developer tools, enable mobile view.
- Select "Surface Pro 7" (Vertical 912x1368 - use "Rotate" if needed).
- Open the menu with the hamburger icon.
- Click on the "Rotate" button.
- Open the sub-menu by clicking on "Home".

=> The menu was displayed within the navbar causing a vertical scrollbar
to appear.

task-3247552

closes odoo/odoo#117899

Signed-off-by: Colin Louis (loco) <loco@odoo.com>

This commit modifies the label of the alignment option for the
"magazine" and "hamburger-full" header. It changes the label from
"Mobile Alignment" to "Alignment" when the "hamburger type" option is
set to "off-canvas." This is because in this case, the alignment also
affects desktops.

The bug was introduced by this commit [1].

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



task-3254619

closes odoo/odoo#119640

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

When the name given when creating a new page starts with a slash, the
werkzeug route `/website/add/<path:path>` cannot be matched. This leads
to wrong navigation situations.

This commit removes any leading slash from the entered page name.

Steps to reproduce:
- Create a page.
- Enter "/abc" as name.

=> A 404 error page was reached.

task-3328827

Part-of: odoo/odoo#122669

Steps to reproduce the bug :

- Add the same google font twice with the font family selector in the
option tab of the editor panel.
- The font will be displayed only once in the font selector menu but 2
trash icons will be added, one for the added font and one for the font
that was already there.

This commit fix this and allows now the user to add the same font twice,
but only to replace a served font by a local font. The opposite does not
make sense, but if the user really wants to replace a local font with a
served, it is always possible by deleting the locale beforehand.

In addition, this commit adds a cloud icon next to the default fonts of
the theme. Since these fonts are served by Google, it is logical to have
the cloud icon. This is consistent with the cloud icon that is present
when the user adds a font served by Google.

task-2998689

closes odoo/odoo#103402

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

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".

The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.

task-3323245

closes odoo/odoo#121128

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

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>

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] 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

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>

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>

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>

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

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>

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>

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>

Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.

Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled

Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.

Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.

opw-2976261

Part-of: odoo/odoo#105072

Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore.

E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).

Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working).

The work done at [1] actually needed some more rework than that to
handle two other potential usecases:

- If the confirm dialog handlers' promises are rejected, the dialog is
  not closed (rightfully, like for example allowing to fill an empty
  required input)... but [1] prevented to click on the button again
  forever. With the same example as above, it can be reproduced: if the
  RPC to clone the page fails, I cannot retry.

- If not both confirm_callback and cancel_callback were given, [1] only
  prevented to multi-click on the related button (e.g. if you click on
  "Ok", a RPC which takes 10 seconds is made, you click on cancel
  immediately afterwards -> the dialog is closed while it should be
  prevented (and would be if cancel_callback was given, following [1])).
  That may not be entirely stable to make this change though but it
  seems to make sense and be better (just keeping what [1] wanted here).

Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).

[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b

Closes https://github.com/odoo/odoo/pull/103712


opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104220

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Currently entering custom urls will be missing characters if they contain unicode.

Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`

Expected output after this commit: `noi-dung-co-dau`

closes odoo/odoo#104572

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

The clone page behavior in the page properties and the page manager was
changed with [1].
But it was actually not working anymore since [2]  as the input URL
could not be found, so it was crashing (`this.$ does not exist`).

This commit repair that clone page dialog but it is actually only fixing
the consequence of the issue and not the root cause as it should.

A deeper fix fixing the root cause will be done at [3].
In the meantime, this commit will be enough to prevent the issue as we
have more and more opw about that.

[1]: https://github.com/odoo/odoo/commit/4e340cc5f0c1fe9de17a2b852de4faf65a33926a
[2]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[3]: https://github.com/odoo/odoo/pull/104220



Courtesy of daramousk for this fix

opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104372

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

*: web_editor

Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.

This fixes the problems with an ugly patch. We'll review what to do in
master.

Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.

[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3



opw-3031217
opw-3032482
opw-3035289

closes odoo/odoo#104156

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

This is a backport of [1] from Odoo 16

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

Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.

This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.

It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.

What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.

Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).

Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.

Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
  won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
  differentiate essential and non essential cookies and to allow user
  to accept only one or both (task-2800976).

Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
  ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
  The German law about this

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



Closes #83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)

Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt

closes odoo/odoo#103389

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