With this commit, users can no longer have headers that have the sidebar
template and the over the content option at the same time.
Steps to reproduce the problem:
- Edit a website
- Edit the navbar
- Set Header Position to Over the Content
- Change the navbar template to Sidebar
The navbar is not displayed properly and there is a margin on the left
that should not be there.
task-2877421
closesodoo/odoo#95463
X-original-commit: 618fd49642310c7b97ef3b9e6c01f8f691c7b12f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the switchTheme option was redirecting the window to
the theme_install_kanban_action url.
After [1] was merged, the editor is instantiated inside the webclient
and the action can now be opened directly from there, without a reload.
For that, the request_save event data can include an 'action' parameter,
which the WysiwygAdapter will use after leaving debug mode to trigger
the action with the action service.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#81485
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website_modules
This commit restores the display of the website loader (the "Building
your website" GIF) during the installation of a module from the new
content modal, or after completing the configurator flow.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, clicking on the edit button of a slide viewed in
fullscreen mode would instantiate the wysiwyg, remove it, exit the
fullscreen mode et re-instantiate the wysiwyg.
To prevent that, the editor component never starts with the wysiwyg
shown by default when mounted. Before that, it checks if it should
redirect somewhere in the publicRootReady method (if not, it shows the
wysiwyg).
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, switching languages from the language dropdown while
in edit/translate mode was broken.
Now, the click event on this dropdown is listened alongside links with
external redirection from the WebsitePreview client action, so that the
client action leaves the edit mode while frontend is redirected to the
right language.
For that, a new leaveEditMode method is added to the website service,
which removes the edition classes and unmounts the Editor component.
This will further be reviewed in future commits.
Also, adding a new language from the language switcher dropdown directly
opens the wizard in a dialog on top of the WebsitePreview client action.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
This commit adds the PagePropertiesDialogWrapper and
AceEditorComponentAdapter as children of the client action, instead of
the NavBar. Both of the components are displayed conditionally based on
the websiteContext. It allows us to remove the navbar xml patch.
With the PagePropertiesDialogWrapper rendered only when needed, it can
open directly the appropriate dialog in the onRendered hook, so that we
can avoid passing the widget to the parent that would later open it.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
- new prefix `bs-` for the root CSS variables
As some website snippet relay on these values we need to restore the old
behaviour by setting this prefix to an empty string.
- restore negative margins disabled in BS5 by default
- restore BS4 behaviour for setting element content
Fix some cases when we want to render more than one node on the root
level.
In BS4 the jQuery was using all node but in the jQuery compatibility
layer in BS5 it takes only the first node if the jQuery Element is used
in the function. This hack try to restore the old behaviour wrapping all
element in a DIV element (to be single root node).
PS: this can break some querySelector and some CSS selector if they are
too fragile.
e.g. of element that break before this hack:
Popover content for PaymentPopOver XML in ShowPaymentLineWidget
- restore old value from BS4 and adapt to new value
$table-cell-padding -> $table-cell-padding-x
$table-cell-padding -> $table-cell-padding-y
$table-cell-padding-sm -> $table-cell-padding-x-sm
$table-cell-padding-sm -> $table-cell-padding-y-sm
- restore BS4 smooth-scroll behaviour
- restore `text-X` from BS4 that use text-emphasis-variant
In BS5, to generate the text utilities `test-X` its use BS5 utilities
(See $utilities SCSS variables). To restore the old behaviour we replace
with the custom `text-emphasis-variant` mixin.
See odoo/odoo@e111cfd35e
- restore border and background of table
In `_reboot.scss`, BS5 add `border-style` to all element of a table.
In some case we customize the table with CSS rules (e.g. `listview`),
these rules set a size of border. The mix of all rules made that the
border of the `td` in `tfoot` are visible and make a black line.
- reset block quote Y margin to 0
BS5 add a spacer and we reset that by puttin margin-y 0
- In BS5, border color is linked to the text color in it. We doesn't
want that and we restore the same behavior as un BS4 by putting
border-color in grey.
- restore HR style like in BS4
Since in BS5, the height matter we remove the padding and added into the
margin.
Also, we restore the color of BS4 for the HR tag
> <hr> elements now use height instead of border to better support the
> size attribute. This also enables use of padding utilities to create
> thicker dividers (e.g., <hr class="py-1">).
https://getbootstrap.com/docs/5.1/migration/#content-reboot-etc
- restore old value for grid gutter to avoid calc error
In BS5 `$grid-gutter-width` is set in rem and in BS4 it was in px.
So SCSS compiler generates error when it tries to calc rem and px.
- restore badge, navbar paddings like in BS4
- restore link decoration in frontend (Portal) whiteout website
Task ID: 2766483
Part-of: odoo/odoo#95450
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
Converted for new Javascript of Bootstrap 5.
Note: some parts are removed as not found equivalent function name in
BS5.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
Issue introduced by commit b0a2a41
The template's "flags" value was not in the t-nocache values to use when
rendering languages.
X-original-commit: 7827d2dbc1fbef3cc0dc898baa0af30ed1f23fca
Part-of: odoo/odoo#95222
Commit [1] made a mistake of copy/pasting the "list_website_pages" ID in
two views related to the "search in everything" and "search in pages"
views (used when checking all results after a search using the "search"
snippet that you can configure to search in everything or in pages).
At the time, that ID induced some CSS rules and JS related to the page
manager (not made for visitors).
- For the "search in everything" page, both the CSS rules and JS had no
effect (except instantiating an useless widget in JS).
- For the "search in pages" page, the JS had no effect (except the same
instantiation of an useless widget) but the CSS had an impact on the
`<table>` used to display the results:
- The header used an hardcoded odoo-purple background color.
- The table paddings were not the ones defined by the theme.
Of course, in custos, more of the CSS could have had an impact (for
example some icons would use bootstrap blue info color by default for
no apparent reason).
Since [2], the page manager was removed (converted into a backend view)
so the CSS and JS rules actually became totally useless. The JS was
removed with [2] but the CSS was kept thinking it was necessary for the
"search in everything" and "search in pages" pages.
This commit removes the useless CSS and the useless ID in the two views.
It also modifies the "search in pages" layout a bit.
A fix could be made in stable later on to at least remove the hardcoded
odoo-purple background color in the "search in pages" page. The rest
should stay as per-stable policy.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#95272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Odoo-Editor, having originally been developed with the purpose of being
a standalone library, was put into a `lib` folder. Since in the meantime
the library plans were aborted and since its presence outside the `src`
directory makes translations unavailable for it, this moves the editor
to `src/js/editor/odoo-editor`.
task-2880723
Part-of: odoo/odoo#94516
This commit ensures that the slideout footer is visible by the visitor
before start its animations. Now to start an option in the footer
slideout, you have to scroll enough for the element to be visible.
Steps to reproduce the fixed bug:
- Enter edit mode
- click on the footer
- choose a slideout effect other than "Regular"
- set an animation to an item inside the footer and select "Everytime"
in Animation Launch
=> the element is animated only once on page load (because the footer is
actually directly in the viewport but behind the content of the page)
task-2878421
closesodoo/odoo#93133
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Introduced with [1] the goal of this tour was to check some lazy loading
stuff regarding the edit mode.
It was then "wrongly" adapted with [2] where the tour actually still
started in the frontend and then clicked on a the new UI button (top
left floating icon of the frontend > backend task) to indirectly enter
edit mode.
While it was working, that's not what the test was aiming to test. The
test should remain as it was, testing the edit mode. While the edit btn
is now in the backend and not the frontend, the tour should just start
there.
Note that this commit is required as the behavior the tour was now
relying on is removed by the previous commit: the Edit button is not
entering edit mode anymore.
Instead of adding a new step to click on the Edit btn, let's just start
the tour as before on the step where you can click on Edit.
It will make the test less dependent of other behavior. This is
especially true since that frontend "Edit" button will most likely
change again or be removed (and introduced back?). We don't want the
tour to rely on this.
If those new UI button need to be tested, it should be in another test.
[1]: https://github.com/odoo/odoo/commit/6f4c60fe1bb6e460ec6da00c59a9825271893729
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35closesodoo/odoo#95002
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
As result of moving the "website into the backend" [1], a new floating
nav has been introduced allowing the user to go to the apps_switcher
or to edit the current page.
This commit slightly refine the design and changes the animation
behavior that it's now triggered on :hover rather than onClick.
It also changes the "Edit" btn url that it's now pointing to the backend
rather than to the editor.
As positive side-effect, these changes improves mobile's UX, allowing to
toggle-back the navbar by simply touching the outside area.
Also, thanks to the use of SVG, it solves the annoying issue of .fa
icons transformations forced to 'none' on mobile.
note: as a preexisting FIXME note says, an xml template should be
created for this component. This commit is intended to improve the
behavior with the current temporary implementation.
[1] https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2898212
Part-of: odoo/odoo#95002
This commit fixes an inconsistent behaviour in tours using the website's
"Edit Menu" dialogs.
When adding a mega menu, two dialogs are displayed:
- The main "Edit Menu" dialog, from which you can open
- The "Menu" dialog with the mega menu label input
When these two dialogs were opened, and closed successively (click on
"Ok" to confirm the menu label, then click on "Save" to save the new
website menu), the tour was sometimes triggering the primary button of
the wrong dialog.
Two issues were leading to this inconsistent behaviour:
1/ Sometimes, the tour would click twice on the same primary button,
and would not wait for the current dialog to close.
To prevent that, extra_triggers are added to the steps to check that the
first click was correctly taken into account (and so, that the upper
dialog, that was the active dialog, was closed).
2/ Other times, the tour would click on the wrong dialog primary button
(it would click on the inactive dialog's button that would save the menu
without validating the label first).
This was coming from the web_tour.TourManager inaccurate
$modal_displayed property, which was defined and used in two different
javascript threads of execution. It could reference modals that were
not the actual modals from the DOM, when used in _check_for_tooltip.
To prevent that, that property is set inside the method it is used in.
It could be defined as a const and not a property, but this way the
commit history is left untouched.
runbot-4000
runbot-4001
runbot-4004
runbot-4005
closesodoo/odoo#94924
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] moved the edition of the website in the backend and
introduced an iframe as the editable. In doing so, some tour
actions became unstable.
The issue is that previously, when an action reloaded the page, the tour
service would reload as well. This is no longer the case and the tour
service stays active when the page is reloaded (e.g. when saving a
page). This can lead to a tour clicking on an item before it is ready to
be clicked.
Specifically in this case, the tour saved and clicked on edit as the
next step.
Clicking on edit before the page is properly reloaded leads to the click
being ignored.
This commit uses the util function `clickOnSave` which ensures we're out
of edit mode and the page is reloaded before doing anything else.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4074
closesodoo/odoo#94932
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website architecture has been refactored for the internal users and
admins with [1].
Now, they can access the website in the backend inside the website app.
Long story short, the website will be displayed in an iframe in a client
action. The URL of the browser will be tweaked to reflect the iframe one
instead of the real one (which is something like /web#action=..).
It had a few drawbacks:
- On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
- When the user edited the URL (Like removing `/shop` and typing `/jobs`
instead, he would land on the frontend version too.
- Impossible to directly go to the backend version of the website.
Those are improved with this commit by using a slightly different URL
when we are in the backend. A `/@/` will prefix the iframe URL.
If logged in, the user will land on the backend. If not, it will simply
redirect to the frontend version of the website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#94580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Whenever the user hit ctrl+k when being on an html field, both the
link dialog and the command palette opened.
In order to resolve the conflict, now ctrl+k open the command palette
with the first entry being the command to open the linktool and
a subsequent hit to ctrl+k when the command palette is open to open
the link dialog.
Task-2738457
Forward-port-of: #89940
Forward-port-of: #82994
Part-of: odoo/odoo#91102
The vertical spacing between images of an images wall was lost when a
link was added to an image.
This commit applies the bottom margin to images even if they are
within a link.
Steps to reproduce:
- Drop an "Images Wall" block.
- Add 4 images to the wall.
- Add a link to the first image.
=> The gap between the two images of the first column disappeared.
task-2818919
closesodoo/odoo#94822
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce (in slow 3G):
- Go to the website app,
- The "Optimize SEO" menu is not available while the iframe is loading,
- Wait for the iframe to be laoded,
- Go to another app (discuss for example),
- Go back on the website,
- This time, the "Optimize SEO" menu is already available,
- Click on it, it crashes.
The website metadata from the website service were not correctly cleaned
when leaving the website_preview client action. When going a second time
on the client action, the "Optimize SEO" isDisplayed method was based on
outdated metadata.
This commit resets them when the pageDocument is set to null (when
leaving the client action).
task-2687506
closesodoo/odoo#94631
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes a race condition happening when clicking on the "Link
Tracker" menu of the website, when the website_preview client action's
iframe is not loaded yet.
That menu uses the iframe's contentWindow.location (taking it from the
website service), which was not set before the "load" event of the
iframe.
With this commit, the contentWindow is set at the website service level
when setting the pageDocument, as it can be taken from it
(document.defaultView), and the link tracker is displayed only when
there is a contentWindow at the website service level.
task-2687506
Part-of: odoo/odoo#94631
The drag and drop mega test is quite simple: the python gets the list of
all the snippets (by rendering a view + etree), then it just starts a JS
tour by passing all those snippets in the tour URL.
From there, the JS tour is in charged of building its own steps based on
the list of snippets it received from the python.
The MOST important part is to be 100% sure that the built steps are as
expected: ~5 steps / snippets: ~220 steps with website only and ~280
steps with all modules.
If we don't have that check, the tour could suddenly not test anything
because the step list would be empty, but the test wouldn't fail.
Thus, we don't want to programmatically try to compute that step amount
but want it to remain an hardcoded number, which is lowered in this
commit as if we have 220 (it could be 200, 150..) steps, it means that
the steps were built as expected.
Note that since the test is run on post_install, 280 was fine since all
modules were installed.
But the nightly build is also testing this test with only the website
module, ultimately failing.
Note that this check was actually not working at all since [1] as there
was a typo on `length`.
[1]: https://github.com/odoo/odoo/commit/61b19dafd1fb79120f701b94038bbe859aa2e271closesodoo/odoo#94614
X-original-commit: 23c6b49ba43e6146143bf83bdfd7ce93934961ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a new menu item in the "Site" menu section.
This "Edit Event Menu" item is only shown when a [data-content_menu_id]
element is displayed within the iframe (such data attribute is added on
the event menus).
The contentMenuId is taken from the currentWebsite.metadata to keep data
taken from the iframe's document centralized in the service.
The spec is different from the previous implementation, that was
prompting a dialog to select the menu to edit, before prompting the
dialog to edit the menu. Here we have two different dropwdown items.
See merge commit for more information.
task-2687506
This commit hides the Edit button when visiting a page that is not
editable (e.g. sitemap.xml, a link to an image, etc).
See merge commit for more information.
task-2687506
*: web_editor
When installing an app from the web_editor, it's needed to actually
reload the webclient, or some apps might not work properly as they
won't have the right assets loaded.
See merge commit for more information.
task-2687506
By starting the get_switchable_related_views request when the
WysiwygAdapter is started, and awaiting it only when we need to know,
we can improve the initial loading time of the editor.
See merge commit for more information.
task-2687506
When clicking on save while having a popup open, in some conditions,
a traceback can appear due to a race condtion.
This is caused by an event listener which updates the visibility status
of said popup in the editor panel. When saving the popup is closed,
and the cleanForSave starts, but while the popup is closing an event
is triggered which recreates editors (_onSnippetOptionVisibilityUpdate).
This commit aims at mitigating the appearance of this race condition
by listening to the .hide event instead of the .hidden, which means
the event is fired right away instead of 400ms later.
See merge commit for more information.
task-2687506
This commit adds the autofocus on inputs on form inputs.
It also adds inputs validation on the Edit Menu dialog, and
autocomplete.
The validation is done with a useControlled input hook, taking an
initial value and a validation function (isEmpty, ...). It returns a
state holding two value: the actual value of the input and the boolean
hasError (used to display or not an is-error css class), as well as the
validation function, wrapped to update the hasError state value.
The existing jquery autocomplete widget is reused, with the a mapping
object (a fake widget that will use the Component's rpc service instead
of the legacy Widget's one).
See merge commit for more information.
task-2687506
Before this commit, the welcome message was removed at the level of the
client action, independently from the wysiwyg initialisation.
As the welcome message is directly inserted into the iframe's
contentDocument, it could lead to a race condition with the editor's
observer: if the wysiwyg was already started when the client
action was removing the message, that mutation was recorded in the
history (therefore, when switching to edit mode and clicking on discard
would show the "Are you sure to discard ?" toaster).
Now, the welcome message is removed before starting the wysiwyg using a
removeWelcomeMessage callback.
See merge commit for more information.
task-2687506
This commit mocks the website service for all the QUnit tests.
As the website module now defines a patch on the WebClient and NavBar
components, adding the website service, this service needs to be mocked
for all the tests. This is done by patching the QUnit.testStart hook.
Also, after the addition of the new media dialog, this component is
mocked at the field html unit test.
See merge commit for more information.
task-2687506
The cancel dialog is now using the new Dialog API and disables buttons
when the process is ongoing.
This is needed because prior to this commit, the iframe would reload,
but it would still be possible to click on the buttons.
So one could cancel then click on save and a traceback would show up.
See merge commit for more information.
task-2687506
As there are now two different documents at the SnippetsMenu level, in
the context of the website app:
- the iframe's one, where the snippets are,
- the global one, where the SnippetsMenu is,
Focusing a contenteditable snippet would not blur an option's input and
the other way around, leading to wrong behaviours.
One of them was the creation of a link via the link tools:
- Drop a s_text_image snippet
- Click on the first paragraph
- Create a link via the link tools
(The paragraph is still selected while entering the url input)
- Click on the newly created link
- Click on the "remove link" popover's button
-> Traceback, as the selection was not correctly set
To avoid that, and restore the one-document-behaviour, we remove the
selection of the global document when clicking on the iframe's document,
and we remove the iframe's document selection when clicking on the
SnippetsMenu.
See merge commit for more information.
task-2687506
Before this commit, switching websites with custom domains was not
properly done: the client action should redirect to the custom domain if
there is one, instead of only redirecting the iframe.
The redirection was not correct for the "go to website" buttons either:
in that case, the url was incorrectly generated for the redirection (the
custom domain was passed in the path parameter of the client action).
See merge commit for more information.
task-2687506
qsm-odoo