In mass mailing edition, in some configuration of:

- being in a modal or not
- size of window
- zoom level

we might get an error when getting the scrolling element.

For example when editing a mass mailing, if I set my viewport to 595
pixels height and have a 90% zoom, the editor is broken.

This is because in SnippetsMenu.starts  `$().getScrollingElement()`
doesn't find an element that has the height of body. In my use case body
height is 329.111 pixels, and scroll height is 328 pixels.

Testing different zoom level and viewport height, the maximum difference
I was able to get was 1.25 so this commit increase to 1.5 the maxmimum
difference.

opw-2455727
opw-2469174

closes odoo/odoo#69592

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

To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.

Fixes https://github.com/odoo/odoo/issues/63306

closes odoo/odoo#67961

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

*: web

task-2276974

closes odoo/odoo#66049

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

*: web, website

Make the empty oe_structure messages "wizz" when the user clicks on a
snippet to drag instead of dragging it.

Part of https://github.com/odoo/odoo/pull/60837
Related to task-2363616

closes odoo/odoo#60837

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

*: web, web_editor

Since the right-panelization made with [1], the modals were not
compensating the body scrollbar when opened anymore and the backdrop
was misplaced. This commit fixes the problems generically, to support
modals with non-body scrolling.

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

closes odoo/odoo#58414

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

*: web, web_editor, portal, account, website_blog, website_forum

This is probably not ideal to move the scrolling behavior out of the
html element but this will be needed for the editor to not have a double
scrollbar on the right. This is actually also useful for the scrollbar
to appear under the purple odoo menu instead of its right.

This commit, if to be reverted in the future, however contains many
improvements to make the transition easier that should be kept: jQuery
and Odoo functions to be able to scrollTo a specific element, get the
top scrollable element, check if an element is scrollable, etc. Also,
some magic was done: if some code tries to scroll to a specific scroll
position via jQuery's scrollTop or animate functions on the html/body
element, those will still work as intended (obviously, using the new
utils to do that is however recommended).

This commit also reviews our scroll behaviors to make them more robust
and share the code.

Part of https://github.com/odoo/odoo/pull/57975
task-2344227

This commit adds a new year scale to the calendar view.
It comes with a new view in the calendar, this view displays a
4x3 grid which cells are month views.

Task: 2193921

Issue

    - Install Employees & Dashboard
    - Add employees to kanban
    - Dashboard
    - Hover an employee picture

    There is only the picture visible
    on the page, the remaining space is white.

Cause

    I found several issues.

    1. The pictures are not shown on hover in employees
        But they are on dashboard.

    2. $attach = all `.content` and on dashboard there is
        2 `.content` so the flyout is append 2 times

    3. The move method is trigerred on hover too, it hides
        the flyout if we are not in it. But with attachToTarget
        we are not in it so it's hidden all time.

    4. If everything above is solved, the image is shown but
        not at the correct position because the flyout base
        position is not top 0, left 0

Solution

    1. Reduce the minimum required size to 128px
    2. use closest instead of parents
    3. Don't hide if we have the option attachToTarget
    4. Calculate the flyout offset and replace it correctly
       and set it to position fixed to handle scrolling

OPW-2291493

closes odoo/odoo#54333

X-original-commit: 2c6d692ee40c97d2ae63da64db7623702948407e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

Issue

	- Install eCommerce
	- Modify a product image with one which
	  has more than 1024px width/height to
	  enable zoom (I used: https://bit.ly/2VETQZS)
	- Go on the website preview & hover the image

	Depending on the screen size, a part of the
	flyout is hidden because of overflow-x
	if you want to see it, you should scroll
	right width right arrow key.

Cause

	The flyout has 100% width and is put
	right (position absolute, left: 100%)

Solution

	To avoid this error on all screen size,
	the solution is to compute the max-width
	of the flyout depending on the available
	space on the right.

OPW-2283648

closes odoo/odoo#54222

X-original-commit: c89b4c25ed92542f6fd0279cf3a9e4ef1bac9fa5
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

Before this commit, the daterangepicker always opened below the input,
even when there was not enough space to display it. Moreover, when the
user scrolled while the picker was opened, it wasn't stucked to the
input, so the picker was displayed at a random position after the
scroll.

With this commit, we compute the available space above the picker
when opening it, and if there is enough space, we display it above,
otherwise, we display it below. Moreover, we automatically close
the picker when the user scrolls.

task-2117229

closes odoo/odoo#42161

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>