When clicking on edit in a form with a wysiwig widget inside, that widget would gain focus. It is not the expected behaviour (focusing the first field) and is really an issue on mobile, where the screen would scroll and the keyboard open.
The mouseup event was there to force summernote refreshing the editor toolbar (which will not display which buttons were active until the editor is focused). So removing it still has drawbacks (the toolbar is not up-to-date), but with chm it was decided to remove it as the issue with focus is worse.
Task-2047389 Closes#36360
* web_editor
This commit adds support to set background videos to all the snippets
that already support setting background images (except on parallax
background for now).
task-1920630
closesodoo/odoo#36261
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Varun Raval <var@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
* web_editor, website
Editing the cover images or sizes was not working anymore. When it
worked, it was thanks to the 'o_dirty' class appearing magically on a
cover part... and that magic seems to be gone.
This commit fixes the problem by adding the 'o_dirty' class on all
elements whose content is changed, not only the editable ones (this is
the case for the blog cover: it is a non editable element whose bg
image can be changed).
Note: this also fixes the edition of multiple covers (of different blogs
or posts) at the same time (this could be backported in 12.0 if needed).
closesodoo/odoo#36999
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Just after we first added the library in Odoo (in april 2018), the
library was released in its last and deprecated version (4.0.0). At the
same time, the author indeed split its 'cropper' library into 2 parts:
'cropperjs' which is the core of the original library without jquery
and 'jquery-cropper' which is a jquery wrapper of the 'cropperjs'
library. This commit updates our code to use the latest version of those
two libraries.
Note: the commit also removes the lazy loading of the library which is
useless and maybe breaking since it comes with the editor assets which
are themself lazy loaded.
Note 2: we may want to remove the jquery wrapper in another update and
simply use the standard JS library.
Part of https://github.com/odoo/odoo/pull/36880
task-2059480
closesodoo/odoo#36880
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when rotating an image so that it overflew the
cropper canvas, it was not possible to unzoom on some part of the image.
Now, with the new set of options used by this commit, the cropping zone
and the image can be moved independently allowing to do everything.
Part of https://github.com/odoo/odoo/pull/36880
task-2059480
Before this commit, the overlay cover operation was deferred while an
animation was ongoing on the target element. The problem was that the
animation end event is not triggered if the related DOM is removed
before the animation ends... or simply if the animation is infinite.
When this occured, the overlay never appeared.
Note: this could probably be backported if the need rises.
Part of https://github.com/odoo/odoo/pull/36803
task-2070930
* website_forum, website_profile
- Share some code between website_forum and website_profile by exposing
a function in web_editor to instantiate a wysiwyg instance on a
textarea
- Use no-lazy loaded JS to add a visual loading effect while the
wysiwyg is not yet available.
This is made in preparation of task-2024197
(see https://github.com/odoo/odoo/pull/35749)
Thanks to @stefanorigano
closesodoo/odoo#36581
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website_form
Now, the snippets options are still displayed in the left panel but all
the parent options are also shown (and do not require to toggle them
anymore). On hovering them, the overlay style is turned in preview mode
(even for the sticky one) allowing to see which part of the DOM the
option is editing.
Part of https://github.com/odoo/odoo/pull/36515
When hovering a set of options we display a purple dashed overlay, the
problem is that it was not visible over purple-like colors. Now it is
an alternance of purple and white.
Part of https://github.com/odoo/odoo/pull/36515
* web_editor
When starting a drag and drop in the editor, a series of dropzones
appear to indicate to the user where he can drop the block being
dragged. In the website editor, when an editable structure is empty,
it is filled with a message to indicate we can drag and drop something
in there. The problem was that this message and the design that comes
with it disappeared when starting a drag and drop as it was replaced by
the editor dropzones. Now, the 2 are combined: when a dropzone appears
in an empty editable structure, the message and its design are kept and
just changes color and animation to match the one of an editor dropzone.
Part of https://github.com/odoo/odoo/pull/36515
task-2057320
Before this commit, translations were edited in a list view with a filter
on the field that needed to be translated.
After this commit, the translations for each fields are translated in a
dedicated dialog. The changes done to the current language are taken
into account immediately, both ways, from the dialog to the form and
from the form to the dialog.
Translating terms is also available in create mode, the user will be
prompted to save before editing a translation
Task ID: 2028152
closesodoo/odoo#36185
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The color picker in snippet options has two way to set a color: have a
data-color attribute => it is used, or have a o_custom_color class and
the background-color is set directly on that color.
In the case where we select no background color (transparent), it would
work in preview, but when applied the opaque color of the transparent
button (since opacity is not copied) is set which is wrong and
unexpected.
opw-2053636
closes#36131
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When pasting from clipboard, the editor filters the nodes to paste.
Among other things, it removes `meta`, `style` and `script` nodes. It
did so using `jQuery`'s `not` method but that method has a side effect:
it removes text and comment nodes as well if you pass it a `jQuery`
selector. As a result, unwrapped text nodes could not be pasted. This
commit fixes that by using `each` to remove the targeted nodes instead
of using `not`.
closesodoo/odoo#36012
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Do not remove block in _removeNextEmptyUnbreakable.
Before this commit, when you tried to remove insert a character in
a td, with an empty td after the first one. The function
_removeNextEmptyUnbreakable removed the empty td. It was for
example breaking snippet in the website and mass_mailing.
closesodoo/odoo#32096
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
If you change the color of a link with the editor without using the link
edition menu, this do not work (which might be expected), but if the
text outside the font had been colorized, the font will be applied
outside of the link only.
This is unexpected since if we have: "hello <a>cruel</a> world!", if we
select only "cruel" and change color, the change only happen to "hello"
and "world!".
With this changeset, an anchor in the ancestor prevent to use an
ancestor font tag to change color (which prevent the issue).
opw-2044551
closes#35862
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When a snippet part is removed, like a column, we check that one of
its ancestor has a snippet editor attached and we remove all the empty
element up to and including that ancestor if possible. This way, if we
remove the last column of most snippet, the whole snippet is removed.
The problem is when that ancestor is a main editable area that should
not be able to be removed.
The case is currently probably never occuring but it could be backported
if needed. This is made in preparation of the mega menu task, during
whose implementation it was discovered.
When a snippet is selected, its options are shown in a section named
after the snippet. The name is guessed from the block classes if it
matches those of a snippet or is simply retrieved from the data-name
attribute. The problem is that that data-name attribute was not written
on the DOM but as jQuery data in some case which make them disappear
under some circonstances (like cloning a whole snippet thanks to the
keyboard, etc).
closesodoo/odoo#36217
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now, the snippets options of the selected snippet use a blue color to
match the overlay color. When a block does not have any other option
than being removable or resizable, this helps a lot to see which option
is opened.
* mass_mailing, note, website, website_blog, website_form,
website_mass_mailing, website_sale
This commit, unfortunately, mixes three things:
- Restoring as much as possible the scss organisation to allow styling
the web_editor UI properly.
- Fixing some bugs like a border around the page once the editor is
loaded, no ability to scroll the snippets, etc
- Introducing a whole new UI for snippet options: a left panel instead
of the old dropdown & button overlay.
Note: this commit also do some linting and ES6 convertion even though
some of it has been done in the parent commit.
Note 2: some elements that were removed are still styled in the POS apps
but this is because part of a feature was removed while leaving dead
code behind, this is handled in another PR which is to be merged
(https://github.com/odoo/odoo/pull/36136).
Part of https://github.com/odoo/odoo/pull/36068
task-1942370
closesodoo/odoo#36068
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit aims at linting and converting to ES6 some parts of
web_editor JS to avoid as much noise as possible in UI refactor in next
commit.
Part of https://github.com/odoo/odoo/pull/36068
task-1942370
* mass_mailing, point_of_sale, website
- Lib files were included twice
- Variables files were split but added multiple times in the same assets
bundle
- Useless assets templates were defined or split
- ...
Part of https://github.com/odoo/odoo/pull/36068
Related to task-1942370
Hard to say when this was broken since the current work and revert of
the editor: when dropping a snippet outside of a dropzone it was not
dropped in the nearest one anymore because the dropzones were somehow
destroyed first in the current code.
Part of https://github.com/odoo/odoo/pull/36068
Discovered while working on task-1942370
Since we reverted the saas-12.2 editor in favor of the 12.0 one,
we faced a dilemna regarding how the editor iframe is handled in
mass_mailing.
The 12.0 version was using a special controller to get the website
assets required for mass_mailing while the saas-12.2 version used
a completely different mechanism that was, obviously, not handled
by the 12.0 version.
We did not want to reintroduce the old controllers who were
considered to be a hack to load the assets in the mass_mailing
iframe. However, we were very cautious about changing the editor
itself to avoid introducing new bugs in the editor core of 13.0.
The approach we chose at the end, is to use the loadAsset mechanism
introduced in saas-12.2 to load the necessary assets and inject them
in the mass_mailing iframe. This did not reintroduce the controllers
nor did it require to change the code of the editor itself. However,
it required moderate changes to the wysiwyg interface.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
These modifications crystalize the behavior of the old editor, even
if it makes less sense than the behavior of the saas-12.2 one.
In some cases, the only reasonable adaptation we could do for 13.0
was to delete the tests, as these tests relied on mechanisms of
the newer version of summernote introduced in saas-12.2 which
cannot be easily replicated in the older version from 12.0 that
we are reintroducing in this PR.
It is sad to see these tests go, but we knew this was going to be
something we would lose in reverting back to the older editor.
That being said, since these tests were not present back in 12.0,
we are simply back to the 12.0 state of things, not worse. Don't
weep for them though, they will be back in Odoo 14.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
This commit reverts the saas-12.2 editor by putting back the editor
of Odoo 12.
The saas-12.2 editor was an intermediate work between the previous
editor of Odoo 12 and the new one slated for Odoo 13. It was unstable
but it was supposed to be replaced by the new editor of version 13.
However, since the new editor has been postponed to Odoo 14, the
saas-12.2 one would have been staying in Odoo 13, which would have
been a nightmare to maintain. To avoid this outcome, we chose to
put back the 12.0 editor in its place.
This has the particular advantage that Odoo 13 will share the same
bugfixes as Odoo 12 and 11 as they all run under the same core
editor, while the saas-12.2 one would have been an entirely
different beast to maintain.
This is a partial revert of f2969923.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Summernote was updated alongside the new editor of saas-12.2. However,
since we are putting back the editor of 12.0, summernote needs to be
downgraded back to the version that was compatible with the 12.0 editor.
This is a revert of 17c6d005.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
For the ours need, we can not let the contentEditable behavior. Indeed,
this one does not have the same behavior according to the browser. The
DOM node could be erase, merge, cut, in them according to the keyboard
interactions. The problem is that if we have to manage these behaviors,
we have to manage everything. It was already the case in the previous
version, however before we created an editor by zone and by a hack we
mix the history.
In the case of the virtual keyboard of some OS / Phone, the events are
different and the autocompletion does not update (bug that prevents
modification interactions with javascript). In order to solve these
problems, we use another event for the insertion of the characters.
However, we must also force the update of the corrector by forcing a blur
and a focus.
The current version is a temporary version. We are currently working on a
version that uses a virtual dom and does not need to do excessive prevent
default.
MaxLarue