This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
removeSrcAttribute should avoid these rpc, but for some
unknown reasons, on firefox it works but not with chrome.
Because the purpose of the test is to check the url and
not the content, that works to use an existing route.
Courtesy of @kangol for the fix
There is a slight visual inconsistency since: 9af8d5e6 the xml/less
editor for first level of descendants were just prefixed by an invisible
space.
opw-807624
closes#22704
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
opw-807180
closes#22639
It seems that firefox has some difference of behavior from other
browsers as said in:
- https://bugzilla.mozilla.org/show_bug.cgi?id=548397
- https://github.com/whatwg/html/issues/1813
- https://github.com/w3c/csswg-drafts/issues/571
It seems that at least in one instance (a html field hidden on the pos
configuration), firefox fails because of something similar:
window.getComputedStyle(element) returns `null` instead of the element
styles.
In my tests, using the parent window (possible if current frame and
parent have the same origin which should be the case) worked in this
instance, this is examplified by this jsfiddle:
https://jsfiddle.net/Lpv898ve/2/
This work with window.parent and not using window directly.
So this commit adds fallback on doing getComputedStyle from the parent
window (when testing on chromium this gave exactly the same result that
before).
opw-813363
fixes#22211closes#22610
When clicking on a link in the editor, the "center" alignment button
was always marked as active whatever the real alignment of the link.
This was because it considered the alignment of the text inside the
link instead of the link's one inside its parent.
$('web_editor.base').ready() returns a deferred that:
- wait at least for $(document).ready()
- wait at least for require('web.ajax').loadXML()
- at most once starts translations configuration
But there is an issue since there is unexpectedly no reference to the
translations, whilst it should have also been ready when ready was
resolved.
This commit keep the reference so translations can be used after
$('web_editor.base').ready() is resolved as it was before 7dfdfa0103.
note: in 11.0 it should be solved with 29729769 (so fix is for [10,11[)
opw-804148
closes#22522
Sometimes the formatting buttons had no effect or formatted more than
they should (like a whole column when triple clicking on a paragraph
only). This was because of the `listBetween` function implementation.
This is supposed to return all the nodes between one element and another
one... but the logic is wrong without saying from which *point* to start
and which *point* to end. For example, when asking the list between an
element and its parent, the result is very wrong as there is no way to
go from the beginning of an element to the beginning of its parent using
the `walkPoint` function as the `listBetween` function is doing.
Ideally, the function should be entirely fixed but this can be tricky.
For now, the function is just extended to allow to specify points
instead of nodes, and those are used by the `formatBlock` function to
solve the current problem.
... hopefully.
This *must* be forward-ported.
Depending on the browser, the triple-click behavior is different. This
is especially problematic on Chrome, where blank characters at the start
of the neighbor of the clicked element are selected.
A weak attempt to solve that was made by commit https://github.com/odoo/odoo/commit/b85bd358234684974f9af63bc5f28cfabb527767
This commit hopes to solve all the issues once and for all by fully
reimplementing the triple-click for all browsers. The concept is simple:
when a triple-click occurs, select the whole *inner* content of the
deepest DOM *element* that was clicked.
For some unknown reasons, the editor sometimes crashes when dropping a
snippet. As a temporary fix, the non-critical line that causes the
problem is try/catch protected by this commit.
Changing the `deleteContents` method of the editor is tricky. This
commit however dares to add a behavior: if the range does not
represent a selection but only the cursor position and is then asked
to delete its content... it should not do anything as nothing is
selected.
/!\ Partial backport of https://github.com/odoo/odoo/commit/0a31cb9b4ae461119ecafdd05c5b979621ffb039
/!\ Should not be forward-ported
Before the websitepocalypse introduced in 11.0 (saas-17), when saving a
page in the editor, every `cleanForSave` method of snippet options were
called, even for snippet options which were not initialized (so if a
snippet was left unchanged before saving, the related `cleanForSave`
methods were called anyway). This behavior was bad code and did not make
much sense and was so removed with the websitepocalypse
(see https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8#diff-4c580abda3220e45c6b3f6bdcf77c733L415)
Unfortunatly, the behavior was necessary given the states of our snippet
options. Indeed, for the "latest posts" snippet, the `cleanForSave`
method removes the entire snippet content (as it is dynamically loaded).
The dynamic loading is performed by the snippet *animation*... and
removing the dynamic content should logically be done by the animation
too... which is the case. The problem is that animations are not stopped
before the editor is saved. This behavior was only implemented in
saas-11.1 (for future version 12.0) with commit https://github.com/odoo/odoo/commit/0a31cb9b4ae461119ecafdd05c5b979621ffb039
As a stable fix for 11.0, part of the mentioned commit is backported
here and some specific `cleanForSave` will be reviewed as animations if
necessary. Note: `cleanForSave` made useless by this commit are left
anyway as this is a stable fix.
See https://github.com/odoo/odoo/issues/22089
- Remove useless snippet background suggestions (only one button to
open the media dialog directly)
- Show meaningful-only tabs in the media dialog (no document as
background, ...)
- When editing a background shows the background suggestions first and
show the background suggestions last for standard images. Technically,
this is done by filtering on the name/fname of the attachments and
adding magic name parts to the fname on image upload (e.g. when
uploading an image from the media dialog when customizing a bg, the
uploaded image will automatically be marked as a background). Note:
there were discussions to implement this feature with a tag system for
ir.attachment/s but the implementation's cost was too great in regards
to the feature.
- When editing an existing link or creating one from selected text, do
not show the "Link Label" field in the dialog; it was confusing. Only
show that field when adding a link at the cursor location with no
selected text.
Christophe Simonis