Since 54ea956490 the form view has an
"urgentSave" fallback when the page is unloaded (tab closed, page
navigated away from, ...).
In tours, this translates to new network requests being performed
during the browser cleanup, possibly chaining further into more
network events.
Flag these tours as incorrect (by making them fail if we find a form
in edition mode after receiving `"test successful"`).
Adjust testing of http cases because I've added an empty line between
the signal and the actual message for better readability on complex
error messages.
Also provide opt-out, as for some tours it's difficult to impossible to
truly fix them: the `allow_end_on_form` class attribute can be set to
`True` in order to disable the new behaviour.
To implement this, update the browser runner receive the test class
directly (rather than just the test class' name) for more
introspection flexibility.
Part-of: odoo/odoo#96517
When running test tours logging a message to console.error causes the
test tour to fail. Only one such message can cause the tour to fail, if
other message are written on the console they are simply logged in the
odoo logs. The offending message, however, is only shown at the end of
run, as part of the failing test logs. Arguably, it is better to
include it in the browser logs as well.
closesodoo/odoo#75197
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).
Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.
That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.
Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.
Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
print that, it's formatted to show the exception type, message &
traceback
* otherwise format the garbage that is an "ExceptionDetails" object
If odoo is started with a log-level of "warn" of higher, the logging
record is not emitted at all and thus the handler added by assertLogs
has nothing to process at all. As a result the test will fail.
closesodoo/odoo#40802
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, console.error were catched by browser_js
in order to log them but only value was used on received object,
which is correct only when the received object is text.
With owl arrival, error object may be logged. This
commit add the ability to manage logged object, fallbacking on
a complete representation of object if object is not an error or
description is empty.
closesodoo/odoo#39592
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Xavier Morel