Since commit 8ac1c19fac7615fecd51e670f798d13158a4e53c the odoo brand primary color
changed, which also changed the color of tips. The problem
was that they lose a lot of contrast in the appswitcher.
Force tooltip content font style (size, family, line-height, weight)
so that it does not depend on where the tooltip is in the DOM.
This fixes a problem where the style changed when opening/closing the
tooltip. Indeed, the content dimensions, computed in javascript when
the tooltip is closed were wrong because of the style and the opening
/ closing rely on these values.
Backport of 1 second late commit in master.
* Remove the "?" content
* Use a background gradient
* Use a bottom transparent box-shadow instead of a surrounding opaque one
* Reduce tip size and reshape the arrow
Choosing where to place a tip is a difficult problem.
If placed in the body element, the tip have to be repositionned on each
scroll event which is performance-consuming and induces bugs (firefox
scroll event, tips which is over an element while the anchor is under,
...).
If placed in the anchor parent which scrolls, all the above problems
are solved but when the tip opens it cannot overflow its parent
boundaries, which is not possible in many contexts (modals, ...).
The solution here is to change the tip location when it opens/closes.
When closed, it is placed in the anchor parent which scrolls. This
allows to not have to reposition the tip on each scroll. The tip is
also naturally hidden when its anchor is not visible on the screen.
When opened, the tip is placed in the body, where it can be placed
on the top of anything in the DOM.
The transition from one state to another is not noticable as the
position does not have to be computed when the tip is moved in the
DOM and the animation is purely CSS.
Note: however, this commit does not solve the firefox bug of closing
the tip when the window scrolls. Here, the temporary solution is to
let the tip be wrongly position if the user scrolls when a tip is
opened (this only occurs when using the mouse wheel anyway).
Before being positionned, the tip is at the end of the body, thus
adding a scrollbar... which prevents to calculate the correct x
position of the tip.
The chosen solution is to place the tip at the center of the screen
in LESS before the first positionning. This also prevents the content
to overflow the body and does not break animation of the tip as its
display property is always block.
* Adapt code to handle position/width/padding with pixel-precision
* Adapt overlay to not overflow the screen
* Do not let the content overflow the tip when closed
* Improve the JS/LESS so that its content makes the tip grow
with a bubble effect (instead of using a popover).
* Avoid flickering when the mouse leave/enter the tip or move
between the tip and its anchor element.
* Use text-align:left instead of justify
* Set the content width in JS (to a larger width) to be customizable
* Round LESS variable to avoid values like 266.6666666666
* Set opening direction according to viewport:
- Top and bottom tips open towards the right except if they overflow
the window on this right
- Left and right tips open towards the bottom except if they overflow
the window on this bottom
* Improve the 'Skip these steps' mechanism (which is easier as we don't
use bootstrap's popover anymore)
qsm-odoo