Before this commit, calling do_hide/do_show/do_toggle on a
widget that had been destroyed before being rendered crashed
(because this.$el was undefined).

Obviously, calling those methods in this situation is useless, but
with asynchronous code, it might happen that you call them in an
handler, and they have been destroyed meanwhile.

This commit checks if this.$el is set before accessing it to avoid
the crash.

closes odoo/odoo#65889

X-original-commit: 320c29f5b37d4f02b4d5f7b1b6ff64462b000c92
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

*: web

Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.

This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.

Part of https://github.com/odoo/odoo/pull/44596

closes odoo/odoo#44596

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

This completes a commit that was made for the version saas-11.3 (12.0):
https://github.com/odoo/odoo/commit/1440c8be0337c89e3d67d6d93e614c269c8689f1

Indeed, the logic was implemented for the appendTo, prependTo, etc
methods but not for the attachTo...
This could solve unknown problems in stable versions as well but was
judged too risky to merge there. Indeed, if a real problem occurs in a
stable version because of this, the condition can be added to the
related widget individually.

The problem was found in master: during website edition, the public
widgets can be restarted if an element is edited... but sometimes the
public widgets may be restarted in the same JS stack execution. The
willStart method being async, the destroy method was called before
the start method. This does not lead not any known problem with our
current widgets but will create one for a new snippet being implemented.

closes odoo/odoo#39949

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

Widget class indirectly inherits from ParentedMixin (through
PropertiesMixin).

The Widget's children are destroyed in both the ParentedMixin and the
Widget's own destroy() method.

This commit prevents from trying to destroy already destroyed children
and specifically from looping again on those children (resulting into a
minor performance improvement).

closes odoo/odoo#32174

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775

The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.

closes odoo/odoo#30700

Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.

For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.

The keyboard shortcut branch recently added a method
updateModifiersValue on the widget class, which is used to make a widget
aware of its modifier status (in particular, if it is required).  This
is necessary for the proper navigation behaviour on field widgets, but
should not be on the widget class.

The proper fix is, in my opinion, to introduce a AbstractViewWidget
class which would be used for AbstractField and all custom widgets in
views.

Meanwhile, this commit simply protects the call to that method. This is a
refactoring, but can be merged in saas-11.3.

The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)

This commit includes the following changes
    1) Enable moving forward from field to field using the TAB key
    2) Entering the one to many and many to many using the TAB key
        a. When entering it, set the focus on the "add new line" link or
            button
		b. When adding a new line, set the focus on the field visible
            editable field of the new line
        c. Discard adding a new line with ESC key
        d. If the user leaves the first field empty and uses TAB, we
            will cancel the adding of a new line and move to the next
            field of the form
    3) When a field is required and not filled in, do not allow the user
        to move out of the field using the TAB key (the user is still
        allowed to use the mouse though), mark the field as invalid
        instead
    4) After going though the form once, using the TAB key on the last
        field will move the focus to the first primary button of the page
    5) When the focus is on a primary button (EDIT/SAVE), the user cannot
        move the focus forward using the TAB key. Hitting TAB again will
        display a tooltip telling to hit ENTER to activate the button.
        The mouse is still available to move the focus.
    6) When the user saves, the focus is placed on the first primary
        button of the form renderer (like VALIDATE for a new invoice)
    7) On dialogs, primary buttons should stop the users from moving out
        of them, and showing a popup if the user tries
    8) When closing a dialog, the focus will be moved back to the widget
        that opened it.

This commit does not include the following features
    1) Navigation with the keyboard on a selection one to man
    2) Navigate between tabs in a form using the keyboard
    3) Cancelling the adding of a new line in a many to many using the
        ESC key do not set the focus correctly
    4) Enhancing the focusses fields (like blue underline)

- make delegate/undelegate events private
- remove $el before start
- make replaceElement private
- remove one _ from __render_and_insert... method
- update documentation
- remove make and improve make_descriptive (also, it is private)
- ...