This addresses issues with image dropping and pasting.
1. The code to compute the position of the drop was not always run so
that resulted in a sometimes wrong position (dropping at current range
instead).
2. Images dropped internally within a same document should not be
converted to base64.
3. Dropping an image should apply to it the `img-fluid` class so as not
to break the document's layout.
task-2954499
closesodoo/odoo#105137
X-original-commit: 9c258bf18c17a55f1d22c8a7d1b74f5dd51ee73d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `getTraversedNodes` function sometimes failed to include descendants
of traversed nodes, which should logically be included. Eg,
`<div>[<img>]</div>` where the selection is expressed as `div 0 div 1`:
the iterator is set on the common ancestor, which is the `div`, so it
stops immediately, only returning the `div`. Here we add its ancestors
in every case.
X-original-commit: 0e765277871a57c367d09fc05bb13a9d6670d11d
Part-of: odoo/odoo#105137
When discarding the link dialog, we need to restore the selection in the
editable area. This failed because the selection was recomputed when the
dialog was actually removed from the DOM. This is the same case as a
couple of lines above the restoration of the selection, where we need to
wait for the element to be removed before triggering a focus on the
inserted link.
task-3000250
closesodoo/odoo#104847
X-original-commit: 6b86f6c91fc69bec59f39377e322d79242466d42
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Change isolation link unit tests to cover both deleteBackward methods :
- deleteBackward via direct contenteditable command
- deletebackward via input event ( mobile )
task-3054245
closesodoo/odoo#105066
X-original-commit: 123051fc8b61e27fc8e39f0fed02a58186fca7e3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sometimes the link isolation was broken when
the editor rollbacked some browser behavior :
the content editable was reset on the all editable.
And thus the cursor was able to get out of the
isolated link creating issues.
task-2957000
X-original-commit: 0a04ef6c2617741b90c151c367c1731ed180ad70
Part-of: odoo/odoo#105066
We avoid listening to mutation during test selection "[]" rendering.
Those rendering would be registered by the editor and sometimes wrongly
put the editor in rollback mode.
X-original-commit: cb9348e3f7a95d787337b5c3c8fbba5cf6c9e7c4
Part-of: odoo/odoo#105066
Paste a url in the editor from the URL bar of the browser. If you then
select it all and paste another URL in its stead, the zws inserted by
the sanitizer when deleting the selection ends up in the URL.
This is because the sanitizer moves downward into the DOM tree,
therefore change the link URL before removing the zws in its text child
node. To make sure this can't ever happen, we now remove zws from URLs
when parsing them from the link's text content.
task-3054233
closesodoo/odoo#105045
X-original-commit: c4c9627297c0e3e3977cbfd51129227f8ec1ce3c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In commit [1], a check was added to see if a media is editable in order
to prevent its edition if it is not the case. However, this also had as
effect to block the edition of some grid images. Indeed, as the columns
in grid mode containing only an image have their `contenteditable`
property set to `false`, the images don't pass the check because their
parent is therefore not editable.
This commit removes the `contenteditable` property from these columns
in order to make their images pass the check and therefore allow their
edition.
Tests are also added, ensuring that these grid images can be correctly
replaced.
[1]: https://github.com/odoo/odoo/commit/ddade4346347266b7f699d05865578dc96e2bf98
opw-3028116
Fixes#103234closesodoo/odoo#104899
X-original-commit: d8c374e3e6b31bf88aa42952aadf3379936f7600
Related: odoo/design-themes#617
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When we try to add html data in translated email templates then it does not
remove those extra classes from the html code.
After this commit:
Now those extra classes will remove from the html code.
Task-2985072
closesodoo/odoo#104859
X-original-commit: 5e192a3ccd93c3aafda26abdcfae50ab8f0e053e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a change was added within a field like adding a class (eg. o_dirty,
o_transform_removal, or oe_edited_link), it triggered the
`_observeOdooFieldChanges` mechanism that replace all identical fields
from the first mutated field in the set of identical fields.
The bug appeared when there were two identical in the pages
- field A: first to appear in the document
- field B: second to appear in the document
When clicking on a link inside field B, multiples class could be added
(o_dirty, o_transform_removal, or oe_edited_link) within the fields.
Field A and field B were mutated. This activated the mechanism
`_observeOdooFieldChanges` and replaced the innerHTML of field B with
innerHTML of field A.
That replacement of innerHTML made the reference of the anchor node
in the link tool being outdated and changes made inside that link tool
ineffective.
Step to reproduce:
- Install website
- Go to any page and enter edit mode
- Click on the navbar and in the right panel select Vertical header
- Activate the CTA option in that navbar right panel (should already be)
- Click on the CTA button
- Try to edit the URL in the right panel or any link option (style etc)
The link will not update properly and the history undo create a new
link.
This commit add the ability in the editor to prevent classes from being
taken into consideration in the filterMutationRecords and in undo/redo
and when receiving external steps.
closesodoo/odoo#104872
X-original-commit: e07e149e01646cc2e59c8ac205a5047fd74ae0ba
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
It's impossible to specify a custom color in the text input of the color picker
for the selected text.
After this commit:
It's possible to specify a custom color in the text input of the color picker
for the selected text.
Task-2896109
closesodoo/odoo#104560
X-original-commit: f1f3fcef6cc471fc01da574da26712e643315da6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The dynamic placeholder result was not added in the
editable dom in some situation. When the editor was
in rollback mode `true` after a `commitChange`
( maybe because of a `_toInline` called) the result
of the dynamic placeholder was rollback.
task-3044924
closesodoo/odoo#104343
X-original-commit: e9bd4f020ff4a5dd4240fde9caef0bded9a2e28c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
When checking whether an element was removable or not, we failed to
check whether it was within the editable area. As a result it was
sometimes possible to accidentally delete something outside of it. To
reproduce the bug, insert a link in a blank editor, then press delete
repeatedly until the whole link is gone, and then one more time. This
deleted an element from Odoo's UI.
task-2993740
closesodoo/odoo#104268
X-original-commit: 55e4e0577ac8a62d57f759572b8a5e608c7582b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: mass_mailing, website
Commit [1] introduced data-option-name allowing to name snippet options
without data-js so that their automatic snippet-option-XXX class was
not snippet-option-undefined. This was indeed useful to target specific
options in tours.
The attribute is however a complete duplicate of data-js (if you use
one or the other, it does exactly the same thing). Indeed, you can
define a data-js without a linked JS class (as it is already done). And
if you define both expecting the class using data-option-name but the JS
used from data-js that won't be the case, data-option-name is simply
ignored.
This removes data-option-name. This prepares refactorings that will be
done in the future:
- The way to define option in XML will be reviewed (probably client
side definitions, probably OWL templates).
- Adding data-js will probably require a JS class to exist, but all
option definitions of Odoo will declare one to ease extensions and
stable fixes.
Those are theoretical at this point though. This commit main focus is
simplifying the code.
[1]: https://github.com/odoo/odoo/commit/7b0a147cd43e8e890ebe5a882292a69a5c8c90acclosesodoo/odoo#103988
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When trying to edit a link with mailto, there is an "https://"
added and preventing the link to work successfully
After this commit:
The mailto part of the link is correctly kept as is and the link works.
Task-2961012
Task-2977682
closesodoo/odoo#104064
X-original-commit: a22d6d1859a8f97c3cccdba755392cd13d7eb866
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the table border color was only applied to the
columns (left and right borders).
This commit applies the border color to all borders and adapt the color
to be consistent with the dark mode.
task-2710677
closesodoo/odoo#103162
X-original-commit: fc8a0653c2e98cbda9c1ff60f3a5ea7347aadd48
Related: odoo/enterprise#32786
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit:
The behaviour of the text were not identical in edit mode and after save, the
word was wrapped in edit mode.
After this commit:
To make the behaviour identical by unsetting the default overflow property
in edit mode.
Task-2878307
closesodoo/odoo#103975
X-original-commit: 6177fac863a29c86ed4e5ede8d48aa31da3a8508
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a change was made on the same record, the editor could wrongly
be reset.
Step to reproduce:
- Go in knowledge app
- Click inside the editor outside a template block
- Click on inside a template block
- Click inside the editor outsie a template block
=> The editor is reset
closesodoo/odoo#103947
X-original-commit: d0a079a76c3f5078178717966e3d4caf0987ebf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
the top/right/bottom/left sides
- Edit
- Click on the column => crash
This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).
After this commit, we simply do not show any color for this case.
opw-2803311
closesodoo/odoo#103842
X-original-commit: 484230481cd7195e2c992e673a2b6e627baf505d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a table isContentEditable=false:
- Don't show the resize cursor
- Don't show the table ui menu (which allows to move columns/rows)
Currently in Knowledge, when an embedded view contains a `<table>` element, it
was possible to use the editor to edit rows and columns of the view and it is
not intended. Those table are not editable, and as such the menu to edit them
should not be shown.
Task-3000318
closesodoo/odoo#103805
X-original-commit: aec6b02dacf02f18b53cb8b31ffbb52772f5ac27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reprodue:
- enable any rtl language (arabic)
- move to the product page for exemple
- the page is frozen (dependecy loop in css)
Bug:
when the CSS gets minified the missing semicolon error spreads and
produce an invalid file
Fix:
added the missing semicolon
opw-3019173 3032064 3032250 3035077 3034712 3035077 3023730 3022962
closesodoo/odoo#103699
X-original-commit: 8048bdac4cec56edd92c68f7041b802376f9372c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
In the Website Builder, when clicking on the THEME tab, and clicking on
the "Switch theme" button, the loader behind the dialog was not placed
correctly.
After [1] moved the manipulators inside the iframe, the css rule for the
loading elements was not updated to remove its right value, used to
position the loading element next to the right panel.
[1]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
X-original-commit: 106a5a56a96090ae4adfd9e7b3ea2f93d69dca22
Part-of: odoo/odoo#103562
When two building blocks are one above another, if there is no padding
between them, we notice that the move handle of the columns of the
lower block is located on the upper block. This is a problem when the
upper block is in grid mode because since the mouse is above it, the
drag is considered over this grid, instead of the block from which
the column comes from. The column is therefore "trapped" in the grid,
which is unconvenient.
This commit solves this issue by "canceling" the over if the start of
the drag falls in this situation. More precisely: if the first dropzone
to detect the "over" event when we start to drag a column is a grid
dropzone that is glued to this column, then the over is canceled.
task-3013882
closesodoo/odoo#103107
X-original-commit: 122eb3821a9294e4f6e2d346df942b394ca039dc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit
1) click on a record in a list view
2) change the html field of a record
3) click on the top right arrow to change the next record
4) click on the top right arrow to change the previous record
5) click on the top right arrow to change the previous record
The value is not updated corretly at step 4, retaining the value from the
previous record. The wrong value is then saved at step 5.
After this commit
Properly reset the HtmlField property `currentEditingValue` when
the update of props value does not comes from the editor.
X-original-commit: 39d02c3cdc2d4256b62cd6414369a8cf82efff48
Part-of: odoo/odoo#103034
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.
That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.
related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4
task 3003939
closesodoo/odoo#103038
X-original-commit: 69fdca133b06eb66443635bc52d380233580ef51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this fix it was possible to edit a media that was not editable
because no check existed for such a thing.
task-2962912
closesodoo/odoo#103035
X-original-commit: ddade4346347266b7f699d05865578dc96e2bf98
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Followup of #102259
Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable.
I converted all the new rules to work opposite as before, same for the JS logic which added the class based on mobile device detection (size + touch support).
closesodoo/odoo#102977
Forward-port-of: odoo/odoo#102823
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
This commit adapts the module in order to correctly handle color-scheme
variations.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Add 'black' and 'white' color in the list of backend's $theme-colors to
preserve during website's customization.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
This fixes a bug that occurred when using BACKSPACE to remove the last
character of a text node, if said character was preceded by a space and
said text node was succeeded by a <br>. The space was removed along with
the character. This was simply due to a missing state restoration rule
to handle this specific case.
task-2990229
closesodoo/odoo#102974
X-original-commit: 5e90529388095321da8b504ebf543c4c3054845e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a new .o_field_highlight class which can be used on fields and field
containers to force having a border on fields (e.g. in places where they
are heavily used inline, like Settings, or where it might not be clear
that you are using a form and that these are fields; e.g. sidepanel,
etc.
This class is automatically added when the device size goes below the
XSS breakpoint, or when the device has touch input (our best metric for
mobile device detection, where hovering is not possible).
X-original-commit: 0f0c8e3b9f7c42c5126dc49d3378d41ad76afbf3
This commit refactors the style for borderless inputs and
adds a special class to better manage where they should be used.
closesodoo/odoo#102848
X-original-commit: 6b45cd5f3fbe0986e36401308d19214b689adc45
Related: odoo/enterprise#32609
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The RPC that the m2o widgets used by snippet options make are cached at
the widget level. When two m2o widgets make the same RPC, they are
indeed made twice. This commit just move the cache outside of the
widget instance and thus makes it so the same RPC made across multiple
m2o are cached.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC. Then each further drop of snippet made the exact
same RPC for no good reason.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
closesodoo/odoo#102800
X-original-commit: 8e08c896df9ed5a7a0e559f1dbd8812f87908a39
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a snippet option uses a m2m widget, the domain used for the
internal m2o widget which allows to select records evolves to receive
the subdomain `['id', 'not in', <selected-ids>]` with `<selected-ids>`
indicating the m2m records which are already selected.
M2o rpc are cached... based on the whole query object from which they
are created. The domain is part of that query object.
Both those concepts actually conflicted: the initial RPC when no ID is
selected was made with no subdomain, while the subsequent RPC when no ID
is selected were made with the `['id', 'not in', []]` subdomain. The
cache system did treat the resulting domains as different requests. Now
we avoid adding the useless `['id', 'not in', []]` subdomain as it
should already have been done without a cache system in place.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC with the initial domain. Then on click on the
snippet, a new RPC was made with the problematic subdomain, making the
first click on snippets being needlessly slower.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
X-original-commit: 017a468547eafa3e34f584379d3f05b3ed1db487
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In mass_mailing, the paragraph alignment dropdown menu is wrongly
positioned by Popper since the upgrade to Bootstrap 5. Other dropdowns
in the toolbar had the `data-bs-display="static"` attribute but it seems
that paragraph alignment was omitted by mistake.
task-3002168
X-original-commit: 8a372800b9a035893d9f9ecdf7afce17aef3f1b2
Part-of: odoo/odoo#102734
The iframe in mass_mailing is self-resizing in order to avoid having two
vertical scrollbar side by side. This failed since the conversion to OWL
due to the vertical offset added when resizing having become
insufficient. This adds a class to the <html> element of the iframe to
identify when it's in the context of mass_mailing so we can remove the
overflow visible style that is not needed in this context. This allows
us to remove that vertical offset altogether since the scrollbar
disappeared.
X-original-commit: 4f538911d68afdeca0253f15c9e8ffdbed4e995c
Part-of: odoo/odoo#102734
Before this commit
When clicking on "create" from a form view in mass_mailing, the
"template picker" was not presented.
task-3002100
closesodoo/odoo#102725
X-original-commit: 664d5982663517e8e2f2f87b355fd7d3c72285f1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `scrollTo` method and related utils (jQuery animate, ...) were not
properly adapted to work in the context of multiple documents. E.g. the
website editor code (outside the website iframe) is calling the
`scrollTo` util to scroll to added snippet elements (inside the website
iframe). In that case, the util was performing some searches in the DOM
outside of the website iframe while it was meant to be done inside. The
result was that the scroll was not considering the website fixed navbar
and scrolled "too far".
Another bug is visible only when the scrollbar is left to be the natural
browser one (not on the `#wrapwrap`). In that case, the `scrollTo` util
simply had no effect anymore as the `animate` override of jQuery was not
adapted.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: ab417de98068afaaa12995726c7c6445f075ca4f
Part-of: odoo/odoo#102785
Antoine Guenet