Before this commit, the `applyColor` command returned non-connected nodes
(nodes with no parent) in some not well-defined situations, leading to a Warning
when `selection.addRange()` was called by `_processAndApplyColor` with
such non-connected node as argument.
This commit properly removes such non-connected nodes from the array returned
by `applyColor`.
closesodoo/odoo#117166
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Short read version:
This commit gives the Wysiwyg class the attribution of switching between
the two types of text editor toolbar (floating or part of the sidebar),
instead of the SnippetsMenu class, as Wysiwyg owns the Toolbar instance
and has the methods to configure it.
The switching between toolbars is now done by having one instance of each
type (and properly displaying/hiding them), rather than moving the toolbar
element of place in the DOM and reconfiguring it (button handlers, CSS
classes, displayed/hidded buttons, etc), so that the configuration steps
of each toolbar can be done only once.
The floating toolbar is needed for mailings based on the "basic" theme,
where no sidebar/SnippetsMenu is available. Note that it will be only
instantiated if needed.
Long read version:
The 'basic' theme in mass_mailing has no sidebar (SnippetsMenu), so the
floating toolbar should be available instead, in order to give users access
to the text editor's features.
Commit [1] added the `setFolded` method to the SnippetsMenu class, which folds
(hides) the snippets menu and recovers the floating toolbar from the
sidebar container and vice-versa. While the recovered toolbar works well when
`isMobile` is `true` (although with some minor issues described
below), the one for the non-mobile case does not (as it must be properly
reconfigured using the document's Jquery, and not the iframe's, among other
details).
This commit proposes a different approach to the toolbar recovery issue:
if the floating toolbar is needed (mobile or basic theme), a new Toolbar
instance is instantiated and properly configured. That way the Wysiwyg
instance will hold two instances of the toolbar: the one embedded in the
sidebar (snippets menu) and the floating one. This allows for easy
switching between the two types of toolbar, without the need to run the
configuration steps for the toolbar on every switch.
Such toolbar switching is needed in mass_mailing, where a single instance of
the wysiwyg is kept while the user can switch between different records of
mailings. Some of these records could be based on the 'basic' theme
(thus, no sidebar), and other ones based on other themes that do offer
the snippets menu.
After this commit, the toolbar switching is handled by the Wysiwyg class
instead of SnippetsMenu, as Wysiwyg owns the Toolbar instance(s) and has
the methods to configure it.
The `folded` property of SnippetsMenu and the `setFolded` method are
leveraged by this commit, keeping its original purpose and meaning (except
for the toolbar handling).
Before this commit the floating toolbar for the mobile case had the
following issues, that are fixed by this commit:
- The "table" button was (incorrectly) displayed;
- The default colors of the color picker (the top row) were undefined;
- The 'Link' powerbox command and the toolbar icon should open the Dialog,
and not the LinkTools (part of the sidebar).
Finally, this commit removes the SCSS rules that hide the SnippetsMenu
when the theme in "basic", as its display is already handled by
SnippetsMenu's `setFolded` method, introduced by [1].
[1] https://github.com/odoo/odoo/pull/105472/commits/c589939eeaff928997bf6f9735b19710036f9ad6
task-3133259
opw-3165111
Part-of: odoo/odoo#117166
Before this commit:
When we create a nested list and change a tag of the one of
the list item in nested list and press backspace from start it removes the tag.
After this commit:
Now pressing backspace from the start tag, the tag is not removed.
task - 3147461
closesodoo/odoo#118353
X-original-commit: 7504dc1adc50916b9a408c3307832ab45ed5174b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit prevents pasting content inside a link when it is
empty (ZeroWidthSpace only) or its text content is fully selected,
making the pasted content replace the link.
task-3081254
closesodoo/odoo#118204
X-original-commit: 7d0da7f56904927f93ef3d678083f3219fadfdc9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds the following test cases that were missing in the
unit tests suite:
-Paste an image URL or a youtube URL as link
-Paste text containing a valid URL among other text fragments
-Paste text containing multiple URLs
-Test if the selection is properly restored after pasting content on a
non-collapsed range followed by an UNDO.
task-3099012
X-original-commit: 0167b031bc9238893c5b4f09bbda996ed0ee914f
Part-of: odoo/odoo#118204
Issue # 1: pasting image/video URL as text
This commit removes this command, because it was considered to be useless.
The category names "Embed" and "Paste" for the other two commands
("Paste as URL" and "Embed Image/Video") were ommited as it is no longer
relevant to group commands, as this would result into two categories with
one command each (the powerbox does not display the category name when all
the commands are under the same one - undefined in this case).
Issue # 2: pasting image/video URL + other text fragments
The powerbox commands are not compatible with an image/video URL + text
or multiple URLs. Choosing one of its commands will lead to loss of all
text fragments but the last valid URL.
This commit ensures the powerbox options are only offered when a single
image/video URL is pasted.
Issue # 3: pasting image URL inside an exisiting link
Even though the Editor's specs do not allow a URL to be transformed into
a link when pasting it inside an exisiting link, before this commit,
pasting an image URL inside a link would open the powerbox with 3 commands,
one of them allowing to transform the URL into a link.
This commit ensures the powerbox with the "Paste as URL" command is not
opened in such case. When pasting an image URL inside an existing link, the
image is directly embedded, and other URLs are pasted as text.
Issue # 4: unnecessary regex matching
Before this commit, every text fragment in "text URL text" was being
prepended with "https://" and a match with the URL regex was attempted.
Every fragment (text or URL) was also probed for a match with the
youtube video URL regex, but such matches would be discarded anyway in
modules like note and mass_mailing where the allowCommandVideo option
is set to false.
This commit avoids unnecessary searching with regular expressions by treating
pasting of a single URL (possibly an image or video URL that would lead
to powerbox commands) differently than URLs pasted among other text fragments
or other URLs (see issue # 2 above).
Issue # 5: `historyPauseSteps` with argument
This function takes no arguments. Yet, it was called with the string 'onPaste'
as argument. This commit removes it.
task-3099012
X-original-commit: 3fb93d7e9047a73a8e84f165e2ff52b9887d34a4
Part-of: odoo/odoo#118204
Powerbox commands are grouped under categories.
But this is not very usefull when:
- All commands are under of the same category
- Each command is under a different category
This commit hides the category name when all the commands passed to the
powebox are under the same category.
In order to avoid the second scenario, the commands array should be passed
to `Powerbox.open()` with all commands having the same category name (the name
does not matter), or even with `category` undefined.
X-original-commit: 93d632861996c78502b33538cc7ff06d8419602c
Part-of: odoo/odoo#118204
Before this commit, after pasting a valid URL on a non-collapsed selection
followed by UNDO, the selection was not restored to the original range.
This was due to not recording the selection in the current history step
before creating the link.
After pasting text composed of a valid URL between text fragments on a
non-collapsed selection followed by UNDO, the selection was again not
properly restored. This time, because each text fragment insertion was
done via execCommand, which calls _computeHistorySelection and thus
overwrites the current step's selection.
This commit:
- refactors code for link creation into a single function;
- wraps the link creation at `_onPaste` in a 'insertHTML' command called
via `_applyCommand`, which records the selection properly in the history
step;
- replaces `execCommand` by `_applyCommand` for text fragments
insertion.
task-3099012
X-original-commit: 20bb1a2090c90f87a819fdc1c3bbb332cae3720e
Part-of: odoo/odoo#118204
When assigned the role of restricted editor, there are many ways to
break the web_editor when trying to do actions that should be
unavailable. There is a traceback for the following scenarios under
some circumstances (mainly because of pages without editable areas or
features without the proper access rights):
- Drag and dropping snippet when Restricted Editor.
- Clicking on product when Restricted Editor in /shop.
- Clicking on product image on specific product page.
- Clicking on user name (e.g. Marc Demo).
- Clicking on menu items or logo.
- Clicking on a blog's image in /blog.
- Clicking on a blog's image on specific blog page.
- Clicking on calendar's image in /calendar.
There is now no longer a traceback which makes the editor crash or
freeze. This mimics the behavior in other cases where the editor does
not show a traceback, but there is no message indicating that the action
is unauthorized.
When accessing a menu that cannot be edited, the "Edit the menu" button
is not shown to the restricted editor.
task-2747895
opw-3164176
closesodoo/odoo#118116
X-original-commit: 15c85e4f9f967ee04af3cdeb766d280a2c00731e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce:
- In a snippet in grid mode, resize a column.
- Drag and drop this column in a non-grid dropzone.
- Undo.
=> The column is back in the grid but is still a normal column. The same
happens when doing these steps with a normal column to a grid.
This happens because the class changes are not observed in these cases.
When fixing the drag and drop history in [1], only the style changes
were observed because the class changes are automatically recorded. But
it is not the case after a resize.
This commit fixes that by also observing the class changes.
[1]: https://github.com/odoo/odoo/commit/1dfb127f70832aa9e9022ac337af343b7dc17729
task-3151207
closesodoo/odoo#117854
X-original-commit: 48b3683c4753f1e385ea1692db9c1a15d32cae30
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
This commit fixes some mistakes that were found in the code of the grid
layout option. More precisely:
- When a column was dropped near a grid dropzone (so not inside it), and
if its height was bigger than the grid, the `rowCount` attribute of the
row was not updated to the correct number of rows => there was one extra
row.
- When we start dragging a grid item, if we do not go over the starting
grid at all (it happens if the move handle is placed outside of the
row), the `rowCount` of the starting grid was never updated. This is
because the resize is done at the "out" of the dropzone so if there was
no "over", it cannot be done.
=> As a fix, the starting grid is now always resized when we drop the
column.
- When dropping a grid item inside a non-grid dropzone, its `z-index`
CSS property was not removed.
- When a grid item becomes a normal column, when dropping it in a non-
grid dropzone or when toggling the normal mode, the resize classes
(`g-col-lg-*` and `g-height-*`) were not removed from it.
- When a normal column becomes a grid item, the padding and offset
classes were not removed and the `col-` class was not systematically
synchronized with the `g-col-lg-*` class.
=> The two previous points need to be fixed because after doing multiple
drag and drops, the classes could become inconsistent. This happened
especially with columns whose width changes a lot between snippets (like
with Masonry columns, because of the padding).
- When going back to normal mode, the `--grid-item-padding-*` CSS
variables were not removed from the row.
- In commit [1], a comment that should have been modified has been
forgotten.
[1]: https://github.com/odoo/odoo/commit/67d1b078329600efce414974307d74e9fa9ba9fe
task-3151207
X-original-commit: 4afd418e1a1d4231369aab08dfa5c2d10ca9a310
Part-of: odoo/odoo#117854
In some themes, RGBA colors were used to define the colors of shapes.
However, adding this color in the parameters of the background image URL
of a "shape" element was not valid. This caused several bugs, such as
the colorpicker not finding the colors of the shape used, as well as the
colors of the shape being lost after the application of a "flip".
Steps to reproduce the bug:
- In website edit mode, open the homepage page of the Nano theme.
- Drag and drop a Banner snippet onto the page.
- Bug: The colorpicker does not recognize the four colors used by the
shape.
- Click on one of the two "Flip" buttons.
- Bug: The colors of the shape are lost.
task-2824607
closesodoo/odoo#117652
X-original-commit: 0661aa0bbb4751866cfcc9a320a8eff473ba0442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: website_blog, website
Before this commit, when clicking on a column in the "Blog Posts"
snippet (only with the "Big picture layout" template), the options for
that column were displayed in the editor panel, even if options should
never be displayed for the columns of dynamic snippets.
We had already prevented the appearance of options for elements in a
dynamic snippet in this commit [1] and also in this one [2], using a
'pointer-events: none' to prevent clicking on the elements. However, as
this also removed the mouse hover effect, the 'pointer-events: none' was
changed to 'pointer-events: auto', in this other commit [3], for the
"Big picture layout" template of the "Blog Posts" snippet, so that the
user could see the hover effects in edit mode. And by doing so, we
inadvertently allowed the options to appear again.
In the end, this 'pointer-events: none' was not the right solution, as
for example, for the dynamic "Products" snippet, it may be useful in
edit mode to be able to switch between slides by clicking on arrow
buttons, or to see the mouse hover effects on images (slight zoom).
In this commit, we proceeded differently by hiding the options for
elements that are inside an 'o_not_editable' element (unless they have
the attribute and value 'contenteditable="true"'), excluding them when
generating options so that they don't have associated options.
Steps to reproduce the bug:
- In edit mode, drop a "Blog Posts" snippet in the page.
- Click on the first blog image ("Sierra Tarahumara").
- Bug => Resize options are visible when they shouldn't. The options in
the "column" part of the right panel should also not be visible.
[1]: https://github.com/odoo/odoo/commit/64b663fb42ddca67a06cb067c897abb5a3c4dd70
[2]: https://github.com/odoo/odoo/commit/1345e879d809f811641ea3ad388b5d2c0b16f005
[3]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
task-3054763
closesodoo/odoo#117407
X-original-commit: 80f841e5e33f4694361730d3e015a6a813261685
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reproduction:
1. Switch to French, create a /heading 1, and input nothing
2. The placeholder “Heading 1” is not translated
Fix: add translate function around the terms and manually add the
translations in pot
Note: since OdooEditor.js is under web_editor/static/lib/web-editor,
only the js code under /static/src/ is considered for translation export
The translation is manually added with specific path. In Odoo 16, the
path is changed to /static/src/ and translations can be exported
correctly. The translation code paths added here should be changed in
Odoo 16
Related PR adding translations: https://github.com/odoo/odoo/pull/93272
opw-3224482
closesodoo/odoo#117142
X-original-commit: 5f297854348e073a3915bca5cec13066f6abe90e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
This removes the `clearEmpty` util which was only used in the `enter`
command.
closesodoo/odoo#114178
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This removes a parameter in `isVisible` that made it consider (wrongly)
all blocks as visible. This made it confusing to use because it was
effectively returning fake news by default.
Part-of: odoo/odoo#114178
When pressing enter at the end of a heading, we want to insert an empty
paragraph instead of a new heading. This failed when the paragraph had
a zero-width space in it because we didn't recognize it as empty.
closesodoo/odoo#116558
X-original-commit: 228e7937f818f5606601e575b1d9a2bb87cda99d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a block ends with a zero-width space, the mechanism that skips these
characters when using the arrow keys should not skip all the way to the
next block. This is because this mechanism happens before the browser
applies its own behavior for the arrow key so we want to let it skip to
the next block instead (or we'll end up navigating too far).
X-original-commit: acae237410e43e1cf97fc023568f49cc2e974db4
Part-of: odoo/odoo#116558
Make sure not to remove inline styles when emptying an element.
task-3102841
X-original-commit: 8d0397c99798f05a41276d62a66f47c41f255ef8
Part-of: odoo/odoo#116558
Before this commit:
When we select text and take the selection to the hex input box and then try
again to add a solid color, it gives us a traceback.
After this commit:
Now it did not give traceback.
Task-2965091
closesodoo/odoo#116539
X-original-commit: 981713bd024a98f5d9099bfec8458224dac32a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit:
Applying color on empty selection generate traceback.
After this commit:
Now, able to apply color on empty selection.
Task-3089214
closesodoo/odoo#116435
X-original-commit: b4793caddc52b7f4a6a3510a04604b88387e767e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: web_editor
The table of contents menu entries are generated automatically which
poses a problem in translation mode. The menu translation entries
are not be editable separately, but the users might be trying to.
This commit shows a notification when the user clicks on the menu
entries while in translation mode, explaining that they are generated
from the title entries.
It was initially intended to use a tooltip - but the amount of code
needed to display a tooltip without marking the DOM as modified is
needlessly complex.
To avoid that styles applied on a plain text during translation were
also appearing in the navigation menu, an attempt at adding a span
around them to make sure that their translation was distinct from the
one inside the main content. But this led to the risk of losing
existing translations.
Because of this, and because that situation seems unlikely, any
remaining style in the navigation menu is instead stripped when the
table of content is started to maintain consistency with what is shown
during translation.
An `o_translation_without_style` class has been introduced to indicate
to the synchronization mechanism that only the text must be replicated
for those elements.
For labels that have a different `data-oe-translation-initial-sha` than
their related header, that value is temporarily kept in another
variable, the value is replaced by the one from the header, which make
the synchronization mechanism properly associate them, then on save
the initial value is restored so that the translation is saved for the
right slot.
task-2752391
closesodoo/odoo#116270
X-original-commit: 5776a358e1b42186d2c26c9bc25010a12811f416
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit:
The traceback appears after cropping an image and then trying to crop it again.
After this commit:
Cropping an image and then cropping it again won't give us tracebacks anymore.
Task-3134764
closesodoo/odoo#116262
X-original-commit: 83cf218b131c47b711327a224b0a0fd81406e8c3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, error messages appeared when a user tried to put an
unsupported video on a page of his website, but the user could still add
this bad video on his page, which broke it.
Steps to reproduce the bug fixed by this commit:
- On a page of a website in edit mode, double-click on an image.
- Go to the video tab and type an unsupported URL like google.com.
=> An error message appears but the user can still add the media on his
page which will break it.
opw-3167707
X-original-commit: 32cd18895ffcf40e4fec4c5674fa97f6663c7f0d
Part-of: odoo/odoo#116128
An error during the conversion of the html field to Owl caused the
embedded style of the Mail Debug tab to be lost because they were inside
a `<link>` element rather than in a `<style>` element.
closesodoo/odoo#115863
X-original-commit: 218909a339b2f3937e6d6f72fd0c6ff62aa305ce
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit is the first step towards the addition of various SVG shapes
for the website app.
The purpose of this commit is to add the new shapes SVGs and to sort the
current shape menu into new categories.
The avoid duplicating the shapes added in mass_mailing, the 3 shapes:
- Circle
- Slanted
- Triangle (corner)
Are now in the web_editor, their existing reference in mass_mailing
template have have been changed to their new locations. To adapt to
`b1a3a3b18370ad76280726298602815769dce1c2` the paths have been changed
and a new record for `s_tech_default_image.jpg` have been created in
the new file `mass_mailing_themes/data/ir_attachment_data.xml` since
it's an image only used in themes. (Also removing `noupdate=0` from
the data element in `mass_mailing/data/ir_attachment_data.xml`
since it is the default value).
I also removed the .png and old .jpg of this image since now the shape
is applied directly on the image.
Since the shapes + their image are converted in a base64 img+svg on
save, we can move the assets of the current website shapes in use
without compatibility issue. Therefore these shapes were renamed and
moved their new folder category.
The SVG width and height of the new and previous shapes was set to
600x600 since they are mostly squarish and are going to be rendered in a
square preview in the future.
To simulate the future preview of the shape selection menu, the
`we-button img` width was set to
`$o-we-sidebar-content-field-dropdown-grid-item-height` and the
`we-button` width to `1/4` in the file `wysiwyg_snippets.scss`.
It makes the preview 60x60 and displayed in a four tiles layout.
Note :
- If later on the SVG are rendered as inline-svg rather than base64
the current IDs inside the .svg might conflict if multiple svg are
on the same page.
- The previous shapes might look a bit weird with the squarish ratio
in preview, alternatives solutions should be explored during the
implementation of the new UI.
task-3094258
closesodoo/odoo#110673
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes an issue that causes thin spacing to appear between
two snippets containing shapes. This bug had already been fixed in this
commit [1] but the theme snippets have not been adapted to the changes.
With this commit, the shapes of theme snippets are automatically adapted
when they are dropped on the page.
Steps to reproduce the bug:
- Choose the "Clean Theme" for a website.
- Drag and drop a "Call to action" snippet on the page.
- Drag and drop a "Text" snippet with a dark background before it.
- Resize the window to change the window width.
- At some points, the gap will appear.
[1]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
task-2824607
opw-3069213
opw-3057533
closesodoo/odoo#115004
X-original-commit: 256ff539afe331544ccb58848f1ecd0eecbe4daa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The insertHTML test file was named too specifically while we want it to
test the recently renamed `insert` command, which doesn't only insert
HTML.
closesodoo/odoo#114176
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
In mobile view, when text as well as link is in range the unlink button
in the toolbar was visible.
After this commit:
The unlink button is only displayed when link is in range
Task-3184393
closesodoo/odoo#115161
X-original-commit: 5cab1c90b13074e642f3da3a773c55d37419f90b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
By default, clicking on links in a contentEditable context does not open
the link because it would make it hard to edit it otherwise.
This is a problem now that the views are always in edit mode because it
means the user cannot quickly and easily click on links to open them.
This commit aims to solve this conundrum by finding a middle-ground
between these two use cases, that is reintroducing the oh-so loved
Ctrl+Click behavior that was commonly used in previous versions.
This required two changes:
1. Explicitely implementing the behavior of opening the link in a new
tab in that case since it is not the native behavior in a
contentEditable context.
2. Giving special treatment to links inside a contentEditable context in
the `globalClick` listener introduced at [1] such that the event can
actually reach the custom handler in the editor.
task-id 3188438
[1]: https://github.com/odoo/odoo/commit/47acba560a8954f10bfa97b28daf90047005fdf1#diff-ce4923ebad38db28d4fc17267c93d147c4404feefd42eb140ef990bddbe1a9ffR93closesodoo/odoo#115428
X-original-commit: 8bd6b28f7915d7d84ff42722e5cb4b6f798cb81d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection is outside the editable and the `autohideToolbar`
option is false, `_updateToolbar` will perform computations in order to
update a toolbar that is not visible.
In fact, trying to do so can lead to a traceback, as `getComputedStyle`
is called with a null argument when the selection is not contained in
the editable.
This commit avoids such useless computations and tracebacks by returning
from the function when the selection is not inside the editable element.
task-3171892
opw-3161789
X-original-commit: d4b13a147f2a69628c050a04655452fcb2e6d759
Part-of: odoo/odoo#115299
Before this commit:
When we add a single / on editor and add any extra character immediately after
the first / and press up/down arrow key it throws a traceback error.
After this commit
Now, if any new characters is added after the first / and press arrow key then
it does not throw any traceback error.
Task-3193362
closesodoo/odoo#115202
X-original-commit: 10fc8ecd67687f8bbdbb741664968b513063c824
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In order to make the model reactive, it must not be an EventBus. An EventBus cannot be reactive. So we will add a key bus to the model that will always trigger all events that were triggered on the model before.
Part of task 3179751
closesodoo/odoo#114975
Related: odoo/enterprise#38032
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Many of our users have a default OS/browser zoom of 150% when using a
1920x1080 (Full HD) screen. One cause is that this is the recommended
zoom when using Windows. Whatever the reason: many users have a
1920x1080 screen combined with a 150% zoom... and in that case, entering
edit mode would display the website as it would be on "mobile" devices.
This is because since [1], the website is actually reduced in size when
entering edit mode since an iframe is used, whose size is reduced by
the size of the right panel. Before [1], the right panel would be
*included* in the website which would appear reduced but using CSS rules
according to the full screen width (which also led to other issues but
this is in the past now).
The sidebar was actually 3px too wide. Reducing it from 291px to 288px
solves the issue (at least if the OS task bar is not anchored to the
left/right). Indeed 288px is 1920px / 150% - 992px, where 992px is the
current minimum width the screen must have for our websites to be in
"desktop" mode (below, columns break over multiple lines).
Notice that 1920px / 150% = 1280px which gives the minimum size of the
screen that will display the website in "desktop" mode in the editor if
no zoom is used, which seems like an acceptable value.
Note: reducing the sidebar width even further to support more devices or
more zoom / OS task bar configuration would be problematic as the
sidebar would become too small. It is currently kinda at both its
maximum and minimum authorized value.
We tried solutions to virtually "de-zoom" the website iframe to display
the website in "desktop" mode no matter what but this did not give great
results. On problematic devices, the user still has the possibility to
de-zoom its browser by himself.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#114873
X-original-commit: e3ab91188173a47bdc827d8f0e45efcf7b246a4a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only the immediate parent of a selected node was
checked for HTML content support in order to determine the toolbar's
visibility. This led to incorrectly displaying the toolbar for fields
like the 'list-price' on an e-commerce product page, whose text content
is wrapped in an extra 'span' element inside the field's span element.
This commit fixes it by checking all of the node's ancestors up to the
editable root for the attributes that determine if a field supports HTML
content.
This commit also prevents a server error if the user somehow styles the
product's price (with ctrl+B for example. It's worth noting that such
style would not be kept in the saved version of the page).
lxml.HtmlElement's `text` property has `None` value if the span element
does not contain any text before its first child element
(see https://lxml.de/apidoc/lxml.html.html).
Therefore an element like `<span><strong>42.00</strong></span>` would result
in `None` when reading its `text` property.
The `text_content` method is more suitable for such task as it returns the
text content of an element and its children.
task-3188550
opw-3171669
closesodoo/odoo#114867
X-original-commit: 524ba7f89286aa03ed6a4da30177c9ce7018c59a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
unable to remove blockquote and heading element if first element.
After this commit:
removed element on backspace even if first element.
Task- 3004556
closesodoo/odoo#114727
X-original-commit: f0bbf1aab823524a74a52f694c0564dd23618a90
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit transforms the OdooEditor test utils file into an
odoo-module and makes it available for importing in QUnit tests.
closesodoo/odoo#114643
X-original-commit: df2125b7ce50031f0de8f5d78536d50e6c688dd1
Related: odoo/enterprise#37896
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, whenever a peer had no selection in the editor, no
selection would appear to the other collaborators. It was therefore
visually impossible to know excaltly to how many people someone is
connected.
Now, we set the default selection to be in the first node of the
document.
Additionnaly, some selection were not displayed because the call to
`getClientRects` did not return any rect. By creating a deep range
through the use of `getDeepestPosition`, we ensure to retrieve the
selection rect.
task-3217719
closesodoo/odoo#114583
X-original-commit: f47b306c5f37a43849975e4b7afb2819c80c809e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet <nby@odoo.com>
Pulinckx Pierre (PIPU)