Large form views (containing a lot of fields), e.g. the crm.lead
form view, take a while to render (~ 250 ms). Most form views
contain several (sometimes a lot) invisible fields (invisible="1"),
whose only purpose in the view is to be fetched, so that they can
be used to evalute domains and contexts.

This commit implements a trivial optimization of the form renderer,
which consists in skipping the rendering of those invisible fields.
With this change, we gain ~25% of rendering time on the crm.lead
form view.

closes odoo/odoo#54368

Related: odoo/enterprise#11875
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Since the QUnit config is more strict as to what is allowed to stay in
the DOM after tests, a test has been updated to clean its elements
before the test ends.

closes odoo/odoo#53705

X-original-commit: 33b567a777a69a4da627ff1d62b46ad09127f86d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

* barcodes, calendar, partner_autocomplete, web_settings_dashboard

Make the notification system better, using bootstrap toast component,
and make it available in the frontend.

The toast component allowed to remove some JS code and made the
component customizable by themes but it had to be reviewed/fixed to make
it functional (maybe bootstrap will review its work in next versions).

This work should still be improved because there are still too many
ways (deprecated and not deprecated) to instantiate toasts in the
backend. The goal here was however to make the toasts more modern and
make them available in the frontend.

This work is needed for some tasks. @kig-odoo and @fja-odoo made a
pre-work to instantiate toasts in the frontend for their respective
tasks. This commit unifies the system.

Part of https://github.com/odoo/odoo/pull/32793
task-1970731

closes odoo/odoo#32793

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

closes odoo/odoo#32088

Signed-off-by: Christophe Simonis <chs@odoo.com>

Before this commit, users wasn't able to input values in some
input elements like password, email and phone in mobile.

Steps to reproduce:
- Go to user
- Select Preferences
- Select Change password
- Try to input something
=> The focus was lost and the keyboard disappeared

In fact, a hidden input always have the focus when no other fields
need it. This input is used to intercept a value from a barcode
scanner.

So now, we added some input types to avoid to set the focus on the
barcode input.

The barcode input is now always defined (even if not used in desktop)
to be able to mock a Chrome mobile environment in a test.

opw-1936712
opw-1948266

closes odoo/odoo#31841

Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.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>

This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.

All the helpers are exposed though testUtils.js.

There are 2 kinds of helpers:

1. Assertions
-------------
 * assert.containsNone, containsN, containsOnce check that the DOM
   (or a specific part of the DOM) contains a `selector`. It
   generates a correct error message automatically.
    ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
        -> assert.containsOnce(form, '.o_form_editable');
 * assert.isVisible, isNotVisible check that the DOM has an element
   visible or not. They also check that the element is actually in
   the DOM (before most tests didn't verify this).
 * assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
   properties of a DOM element, and also validate that it is
   applied on a single existing DOM element (before most tests
   didn't verify this).
    ex: assert.notOk(form.$('button').hasClass('btn-primary'));
       -> assert.doesNotHaveClass(form.$('button'), 'btn-primary');

2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.

Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
 ex: form.$('button').click();
     -> testUtils.dom.click(form.$('button'));

New Form utilities: (testUtils.form.*)
 clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
 the control panel buttons of the form.
 `reload` reloads the form data.

New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).

New fields utils: (testUtils.fields.*)
 * editInput, editSelect: allow to change the value of a field,
   using a selector to identify it. They validate that the input
   exists and trigger the change event automatically.
 * editAndTrigger: allow to modify a field and trigger specific
   events after the value change
 * many2one (testUtils.fields.many2one.*)
   clickOpenDropdown, clickHighlightedItem, clickItem,
   searchAndClickItem: use a field name instead of a selector and
   do all the complex mechanism to open, filter and highlight
   many2one fields.

Joint work with aab, dam, ged, mge, svs and vsc.

We use the registry keys as name for the services.