When performing undo/redo on some page, because some unneded mutation
get recorded, the page scroll to another location (either up or down).
This commit add a mechanic that filter out thoses unnecessary mutations.
task-2667885
closesodoo/odoo#79620
X-original-commit: 125730ffd9322d34ef1c7d8d0298457de3e65f90
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Because the `_historyStepsStates` was not fully set at the time of
calling `historyStep` in `historyUndo` or `historyRedo`, the listener
for the event "historyStep" was triggered to early and `historyCanRedo` at
that time could not possibly be accurate.
This commit call `historyStep` after setting all ids in
`_historyStepsStates`.
task-2667885
X-original-commit: 659b530516e13df77eed6254b81e72b8009a71bf
Part-of: odoo/odoo#79620
In the editor, there was a little spot where it was impossible to
click in order to select a text.
Task-2684378
closesodoo/odoo#79642
X-original-commit: 02c0cce926b1252596f10299597a9c984a8341ac
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
Some variables were used in _t function instead of raw strings.
One string was not translated properly.
task-2686066
closesodoo/odoo#79505
X-original-commit: 7c5b475532dca1efea5599fb5a3f61ea646d8267
Signed-off-by: Antoine Guenet <age@odoo.com>
Before this commit, when inserting a new snippet or moving a snippet
that was already in the page would temporarily create hooks (`we-hook`)
in the page. The insertion of thoses hooks would trigger mutation
in the dirty observer (observer defined in edit.js) and mark all
oe_structure for which a hook was temporarily inserted.
Thus, creating unnecessary views in the backend.
Now, the code skip the mutations of the drag and drop hooks.
Task-2567752
closesodoo/odoo#79394
X-original-commit: 1b80fe9b56acea09a6784691561df65fe6349f50
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
Steps to follow
- Edit a report with studio
- Add an inline text element
- Select it
- Select the text in the sidebar
-> An error is raised
Cause of the issue
firstButtonEl is undefined because the style section is not always
present in the toolbar
opw-2674302
closesodoo/odoo#79335
X-original-commit: 45b590d8961d56f8d207c22efbf1ba7188a3b1fa
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When starting the editor in a web page, if there is no content, the
oe_structure is not editable. Adding snippet at that moment will
trigger `idSet` on the node with isUnbreakable returning `false` for
the node that is unbreakable because of the check
`!node.isContentEditable` in `isUnbreakable`.
When setting the ouid for the first time with `idSet`, `getOuid` is
called with `optimize` to `true`. So all the ancestor of a node that
should be unbreakable will have the wrong ouid.
Performing any command to a node with a wrong ouid is suceptible to
wrongly be reverted.
By removing `!node.isContentEditable`, the node will have the proper
ouid in case an ancestor is not editable.
task-2633368
closesodoo/odoo#79108
X-original-commit: 13804df7740317b8198e7c1de418ff019c05862b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the editor hint were not properly
removed because the queryselector was made on
the wrong document.
Task-2678410
closesodoo/odoo#79104
X-original-commit: d582f43d81cb570017ef6ff90159cdb6a7ff2874
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When pasting an youtube url in the website builder, the iframe
was inserted without the wrapper used by the website builder.
Now we use the same wrapper as by adding a video through the
video modal.
task-2668224
closesodoo/odoo#79095
X-original-commit: 0cffd7fcdc631b95795d9d819197e5f91ed8195c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In the website builder, when pasting a youtube url,
we can transform it to an iframe in the editor through the
Powerbox.
Adding the iframe did not remove the text in the website builder.
Now it properly remove the text in note and the website builder.
X-original-commit: a9c363cb2c6a88f7f4b1ef09b8a8f9caf39d8f32
Part-of: odoo/odoo#79095
Before this commit, when trying to delete one
unicode character (e.g. 😍), only one javascript character was delete
but one unicode character (e.g. 😍) could be two javascript characters
as the javascript string is coded in utf-16.
This commit fixes that by calculating the size of one unicode character
from the javascript string.
Task-2658890
closesodoo/odoo#79071
X-original-commit: fea5b87615077f5f41dec8c4d1480f157bbd26ae
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When pasting HTML, we have to be careful not to introduce invalid HTML.
The editor corrected for blocks within inlines but failed to prevent the
invalid pasting of blocks within paragraph-related elements
(eg., `<p><h1>text</h1></p>`). This fixes that issue by unwrapping all
blocks from the copied content when trying to paste within an element
that doesn't accept paragraph-related elements as children.
Notably, this fixes an issue that was caused by that problem, in which
pasted HTML content could not be saved because it was invalid.
task-2632676
closesodoo/odoo#79070
X-original-commit: 9c77834e03516f831a9600f0ba4131c957b3ba74
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When selecting text in a list, the toolbar should show that a list is
selected, and which type. It however failed to do that, which is fixed
with this commit.
task-2638422
closesodoo/odoo#77738
X-original-commit: 2a7436d83abe178bd21c0694edc9825f5d70d65f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Part-of: odoo/odoo#79057
On website, if an iframe was in the page, the iframe was removed
when calling the redo command of the insertion of the iframe (and
also other cases).
The reason is because of a sanitization process that is usefull only
in a collaborative context.
This commit disable the sanitization when the collaboration is not
active.
task-2670597
closesodoo/odoo#79056
X-original-commit: 2b9595a1f2d8ee1c019751d4cb080fe9b9f4c05c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the editor was inside a table in the odoo view HTML,
The KeyDown detected that the selection was inside a table
and was trying to add a row bellow the table outside the editor.
task-2601451
closesodoo/odoo#78396
X-original-commit: d1ced1b5a6ad0099fbdcca2530e1e06034108755
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Sébastien Geelen <sebgeelen@users.noreply.github.com>
The img nodes where being wrongly considered empty by isShrunkNode
because the image was not loaded yet.
closesodoo/odoo#77646
X-original-commit: d18d51191bca8f063effd4a216c3963c187a8767
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Before this commit when computing the deepest position for a non-visible
node, if that node had no next visible sibling it used the previous
siblings, but it still marked the offset within that sibling as 0.
Because of this, the selection sometimes got lost.
E.g. in Firefox, drop an "Image - Text" block and triple click on the
header text: upon changing its color the range got set to the text node
but ending at offset 0.
After this commit if the used node in the "previous sibling" from the
evaluated element, the offset is set to the length of that node.
task-2655176
closesodoo/odoo#77567
X-original-commit: 3c4426c71ebe080bcbd285e271c61bf1580c3afa
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
When adding an odd width images on website, a thin black line is
drawn on its right side. The problem comes from the getSourceCanvas
of the cropperjs library. A translation is applied followed by an other
translation in the opposite direction. However the second translation
was not the exact reverse of the first due to a rounding problem.
The fix proposed here comes from: https://github.com/fengyuanchen/cropperjs/pull/300/commits/a6481c052cfc93ef14dd95a3bd00142215dda36e
task-2652904
closesodoo/odoo#77562
X-original-commit: 53f13979cc363c74a8f4e2cec0d24ca10c6ac11c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Add a plugin for the Odoo editor that includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
- style t-tags to make them stand out
Task-27033
X-original-commit: odoo/odoo@300da82eb4
Part-of: odoo/odoo#77377
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
This matches the behavior of GDocs and CKEditor.
closesodoo/odoo#77115
X-original-commit: a84a6c869b815bf372d81db538b458cd23c99b07
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On very small editors the restriction on the toolbar size
and position could generate issue (blocking text visibility).
So we changed the rules to allow the toolbar to overflow
outsize of the editable zone.
task-2648156
closesodoo/odoo#76710
X-original-commit: 6390a4225ea8a97fd0bc0b267d0d016846d27e46
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Sébastien Geelen <sebgeelen@users.noreply.github.com>
Before this commit if the text selection was lost while the color
palette was used, the color selection was not applied on anything.
After this commit if the text selection was lost, it is restored to the
last selection known in history before applying (or previewing) the
color selection.
Also avoid to remember selections that are not part of the editable.
task-2599771
closesodoo/odoo#76357
X-original-commit: 0e706d508d6e747cff566c33d34b794a321eef5c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Use the method serializeNode of the editor rather than directly
the one from utils in order to only serialize when the collaboration
is active.
closesodoo/odoo#76143
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
344d82c commit changed how the editor `_historySteps` should behave.
Before that commit, `_historySteps` could have 0 steps whereas after
that commit `_historySteps` should always have at least the first step
be a snapshot. When reseting the history, we should now add a snapshot
as a first step. This commit guarantees it.
closesodoo/odoo#75901
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit allows to use the editor collaboratively for any html
field in peer to peer using webRTC.
task-2497931
closesodoo/odoo#75768
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
*: web, website
This commit redesigns the editor toolbar improving its visual appearance
and introducing substantial changes wherever it is rendered.
== "Into-sidebar" design
The grid layout has been refined, improving its components allocation.
For the sake of visual simplification, "list-type" buttons have been
unwrapped from their original dropdown. For the same reason the button
to create a new table has been removed (users will have to use the
command-bar to create a new table).
Table's options have been moved to a section "ad-hoc", visible only when
a table is selected.
== Floating design (backend only)
The toolbar is now white to match the command-bar design.
In order to simplify frontend inheritance, the floating toolbar now uses
grid layout.
== Colorpicker
The generic code necessary for each design has been moved from
'wysiwyg_snippets.scss' to 'wysiwyg.scss'.
The style is now controlled by css variables allowing to customize
critical design properties without the need of SCSS overrides.
By default the design is white(-ish) to match the floating toolbar,
while in 'wysiwyg_snippets.scss' the variables are customized to get the
typical sidebar's dark feel.
Note: despite the task main objective was just to improve/fix the
design, this aimed to simplify design inheritance and reduce the css
too. While inheritance has been improved reducing the amount of
overrides, the attempt to reduce the css partially failed (in the final
lines count must be considered that a new sidebar section has been
created).
The reason is that we currently suffer from a deep and complicated
inheritance structure for this component. The xml template uses default
bootstrap classes that are styled differently depending if loaded in a
community or enterprise environment. This approach leads to overrides
that must cover all the scenarios while further customization must be
taken in account too 'cause the toolbar can be rendered into the sidebar
with a totally different design.
A possible solution would be to detach from bootstrap directly in the
lib using custom classes names, and then @extend these classes
differently according to the current environment but probably not a good
idea as we want the toolbar to use bootstrap for in-website editors (so
they can match the theme correctly) but this has to be reviewed as well
anyway. To be checked.
Part of https://github.com/odoo/odoo/pull/73565
task-2496339
closesodoo/odoo#73565
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Step to follow
1. open any record with a chatter enabled )
2. start to write a log note in the the full composer
3. write a line with at least one character, then shift+enter
-> There is a traceback
Cause of the issue
InputEvent.data can be null
opw-2622051
closesodoo/odoo#75726
X-original-commit: 503bbe7a4d0cdd0aefcb723460210b089732831a
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Some templates contain empty <li> elements for styling purposes
only and should be blacklisted in the context of Odoo editor hints
as these elements are not editable.
task-2550858
closesodoo/odoo#74944
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
If the active element is an Odoo field (ie. a field with the
`data-oe-model` attribute) it means the content should not be
considered html, unless its type is specifically `html`.
If the Odoo field is of the `html` type, the Powerbox should only
be triggered if the active element is _within_ that field rather
than _being_ the field itself.
task-2550858
The command bar hints were not properly text-aligned, and the color was sometime not visible depending on the background.
task-2607335
task-2607337
closesodoo/odoo#75028
X-original-commit: 0cd597558c2da268148ca8871442014edba3fdcb
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The bold command used `assignInlineStyle`, which misidentified when a text node needed
to be wrapped in an inline element in some situations, eg:
`<p>aaa<span style="font-weight: normal;">[bbb<span>c]cccc</span>bb</span>dddddd</p>`
task-2613476
closesodoo/odoo#75015
X-original-commit: a61fe7a338289b9195dfca56389593411daf2401
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Because of css rules, when a space was inserted (which is supposed to close the power box), it wouldn't be present in the innerText string.
It was fixed by using the textContent property instead, which contains all the spaces, including the invisible ones.
This might cause problems in some situation where the markup that the editor is modifying contains formatting spaces.
task-2584101
closesodoo/odoo#74766
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The auto-link making feature would insert two spaces when the user would try to add one space.
It is no longer the case.
Some selection management with the link making has been fixed as well.
task-2584101
When the user selects text, the editor compares its closest block type
with a pre-made list of text types (eg. p, h1...).
In case of a match, the 'active' class is applied on the relative
toolbar component.
This commit will extend the comparison list adding text styles that were
initially missing (= the code, h4, h5 and h6 tags were never marked as
active).
Related to task-2496339
closesodoo/odoo#74925
X-original-commit: 1f1157c7e5c2df1bf318ad3a32e7030c969f5261
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
REASON FOR THE FIX
To correctly display the overlay over a rotated element, we need to
reset the transform of the element, to be able to apply it on the
overlay.
Changing the style of the element in the SnippetEditor cover method
would trigger a DOM mutation, which will result in setting the
odooEditor observer unactive.
The issue was that flushing the observer (when setting it unactive)
would always send an event observerApply, even if no record was
processed.
It was an issue as the SnippetsMenu was triggering a content_changed
event at the reception of this event, which would rerender the
SnippetEditor overlay cover (and create an infinite loop of events).
SOLUTION
To avoid that, the observerApply event is sent only if records were
processed.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
Trying to delete forward a non editable was erasing the first
character of the non editable.
Trying to delete backward one character after the contenteditable false
made the cursor jump before the contenteditable.
closesodoo/odoo#74623
X-original-commit: 9b7d9ad3771579ccb60a1be526f5d7571f64e638
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The generator was quite confusing and also
did not provide enough flexibility for when to
stop traversing and under which condition it is
going down the tree.
This refactor was necessary for a future commit
that require to use the new parameters `isNodeDescendantTraversable`
and `stopFunction`.
X-original-commit: c8d44120b49ac967ac12f3715bdaf83cdff3c4c6
On windows when you copy paste text in and into Odoo (for example in the description when creating a ticket) a traceback occurs.
There is an isWhitelist function which verifies that a node is indeed in the authorized items via the following instruction
`item.matches (CLIPBOARD_WHITELISTS.nodes.join (','))`
But on windows there is a comment node containing `<--StartFragment-->`
Here is the clipboard data on linux and on windows for the same copied text (Hello):
- Linux
```
<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\">
<span style=\"color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;\">Hello</span>
```
- Windows
```
<html>
<body>
<!--StartFragment--><span style="color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Hello</span><!--EndFragment-->
</body>
</html>
```
Except for this additional comment on Windows, the `.matches()` method does not exist.
This PR uses the `Array.includes` function on the item's `nodeName`, which should work in all cases while keeping the same behavior.
opw-2591597
closesodoo/odoo#74029
X-original-commit: 41802bc518b4bcd1c71d8659ac560cb748befd95
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Nicolas Bayet