Nested lists should not have a bullet point in front of them, but the
current conversion of HTML for emails made them reappear.
opw-3136324
task-3166100
closesodoo/odoo#111822
X-original-commit: 11f44de490d7e9c59b76aaade1d31b3041c9fb3b
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when editing a form view, when editing a html field,
the status indicator buttons (the save and discard buttons) didn't show
up until a click outside the html field was done (change event).
Now, the status indicator buttons shown as soon as the input field is
edited (input event).
This is was already done for the other fields in [1].
[1] : 0b2d82282d7f656a9177158fd6117cc2e7a1b4d4
task-id 3147130
closesodoo/odoo#111663
X-original-commit: f56e3bca2456f04616982a9a0e77b8d4c5a0abff
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When there is a problem in the peer to peer network where we try to
recover a connection, retry with exponential backoff instead of
potentially spamming the server indefinitely.
task-3164011
closesodoo/odoo#111802
X-original-commit: fd97295c9cf8b1b0c800f407bb5f538f78cc2665
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the image dimensions were not properly converted
when converting HTML for e-mails.
opw-3144322
closesodoo/odoo#111793
X-original-commit: 1d5c8c9adf18aded19d945cd9b0f72eb9b8bbc72
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The custom table selection was not limited to the editable area bounds,
which means we could end up styling a table as selected, which did not
belong to the editor's scope. This sometimes happened when Firefox
triggered a selectionchange event during the instantiation of the editor
and the selection happened to be in a table outside the editor.
opw-3150654
task-3166078
closesodoo/odoo#111779
X-original-commit: d51aab54775ed541d7955cee032aceed143d3a08
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The CSS rules cache for convert_inline was stored on the edited
document, which is problematic since OWL destroys the document where we
used to just hide it (eg, when switching tabs in the form view).
X-original-commit: d432ebbddae7192eca7215a8489abb3ad91a45f2
Part-of: odoo/odoo#111778
When converting html for emails, contenteditable attributes should be
removed.
X-original-commit: 9b4cff9f6ab8e1738f3fc486875f9e4ab16cea9d
Part-of: odoo/odoo#111778
The video command is supposed to be forbidden in tag-sanitized fields. A
field gets tag-sanitized if sanitize_tags is true or by default if the
field is to be sanitized (and sanitize_tags is undefined). Before this
commit, the video command was not forbidden if sanitize was true,
regardless of the value of sanitize_tags.
closesodoo/odoo#111777
X-original-commit: 96b4edfd40a3c131a7709986fc3e1599c177f986
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The images command was disabled in html fields if the field's view
didn't define the `allowCommandImages` option. This allows that option
to be undefined so it can be overridden by its default value when such
is the case. Before this commit however, the option was always set to
`false` when undefined (the opposite of the expected default value).
opw-3134660
X-original-commit: bf0f17d2c9f19b88d4db2f4e15423ec0c831167f
Part-of: odoo/odoo#111777
When resetting the editor, we need to remove the focus listener if one
was previously added. Otherwise, the editor will try to connect too
much for each resetEditor call.
task-3164032
closesodoo/odoo#111541
X-original-commit: ed73015ee8dc53692026d3bc040ece4226e2c117
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a new feature to the web editor of a website. A "text"
input field has been added to the link editor panel, allowing users to
edit the label of a link.
The label will only be updated when the input is changed, to prevent
loss of formatting (e.g. if one letter is bold).
However, only formatting applied to the entire selection will be kept
(e.g. if you have a "link <b>like</b> this", nothing will be in bold if
you update the label in the editor panel).
Additionally, if there is a media element (such as an image or icon)
included in the selection, the "text" input will be hidden.
task-2900529
closesodoo/odoo#99239
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
When changing the padding of the grid items with the `Padding (Y, X)`
option (when the grid mode is toggled), depending on these items
content, the effects are not always visible.
This commit adds a highlight effect on the grid items when the padding
is changed, to better show the changes being made.
task-3058630
closesodoo/odoo#111584
X-original-commit: f3f2c4c73ce08d3898b8c88e1ef045f7bbd1f624
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since the migration from bootsrap 4 to bootstrap 5 and more precisely
since [this commit], the tooltips on too-long titles are not displayed
anymore in the mail editor.
Steps to reproduce the bug:
- Go to the email marketing application
- Create a new mail (other than plain text)
- Go to the design tab of the editor
- Put your mouse over the title "Secondary Butt..."
=> The tooltip to display the entire title does not appear. This commit
allows to correct this bug and to display the tooltip as it was the case
before the change of version of bootstrap.
[this commit]: https://github.com/odoo/odoo/commit/23facbfb76c6e8b23137cddda5f5113273555498
task-2777738
closesodoo/odoo#111032
X-original-commit: 1e5c945f462e4a9903f64fd59c89319f9f2589c1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit and on Firefox 109, clicking on a link while in
edit mode on the website app would trigger a traceback.
This is caused by the fact that the LinkPopover widget is contained
inside the iframe while use the ClipboardJS global defined in the top
window.
Indeed, ClipboardJS checks if the target (the button to copy the link)
is an HTMLElement. To do so, it uses the "instanceof" keyword. However,
the __proto__ (what is used for computing instanceof) of the target is
different depending on the browser.
For Chrome, the HTMLElement's __proto__ depends on which "document" it
was created. On Firefox, when attaching an element to a parent, it will
switch __proto__ to the one from the frame from which it is attached.
To fix this, we use the ClipboardJS from the element's instance window.
In any case, using instanceof when working with iframe is a bad idea,
see [1]. In this case, the fix is made because ClipboardJS is an
external library.
Steps to reproduce:
- Download Firefox 109+
- Go on Website and switch to edit mode
- Click on a Link : A traceback appears.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#instanceof_and_multiple_realmsclosesodoo/odoo#111266
X-original-commit: 732848f2b52bea4ebae18cb5adedf581d5112aa6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
With the new 16.0 feature that open any form in edit mode, the html
editor was trying to connect in collaboration each time a record was
opened in a form view that has a collaborative html field.
The peer to peer connection could trigger a lot of rpc because of it's
communication through the bus.
This commit reduces the number of rpc by only trying to connect to
the collaboration network when the user focus the html editor.
task-3151577
closesodoo/odoo#111247
X-original-commit: 9d7aecec811699199e270a5096f00d5cb6f0b15d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Since [1] when selecting item images, the 'Blocks' tab is displayed
while the options are refreshed. This is visible because the image
selection awaits an RPC which therefore allows the browser to render
the 'Blocks' tab selected version of the display.
This commit prevents the return to the 'Blocks' tab to be rendered by
waiting for the image info to be obtained on start.
Steps to reproduce:
- Drop an "Items" block.
- Click on an image.
- Click on another image.
=> The options panel flickers on the 'Blocks' tab before showing the
second image's options.
[1]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2821398
closesodoo/odoo#111094
X-original-commit: d5cb2810968476b82f30582cd0d6cfdbaf351b2b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit, a traceback would be thrown when no options were
passed to `_getEditorOptions` because of a code mistake using the
variable `options` rather than `finalOptions`.
Also, this error revealed that the `this.options` of the wysiwyg could
be wrongly reset if no argument `options` was passed to `resetEditor`.
task-3149085
closesodoo/odoo#111100
X-original-commit: 475775d3dfc230c06c7a2b127b67bc22543e8a27
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
To reproduce the issue:
- Website page (e.g. "Contact us") > Edit mode > save.
- Try to click on the page right after the save (and before the preview
is blocked) > traceback.
In this specific case, clicking in the page will activate the targeted
snippet and initializes its "SnippetEditor" while destroying the
options and cleaning the DOM, leading to wrong behaviors.
The goal of this commit is to fix this issue by simply ignoring the
click on the page during the save process.
opw-3119347
closesodoo/odoo#111030
X-original-commit: 6bf3823c2996af4ec0534ff69471887ac43a8ddf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], a tooltip is displayed on the blocks that can be
dropped in a page so that the user understands that he must not just
click on it but drag and drop the block. Unfortunately, these tooltips
were not well positioned in the email marketing application because the
editor is in an iframe in this application. This commit allows to
position correctly these tooltips.
Steps to reproduce the bug fixed by this commit:
- Go to the email marketing application
- Create a new mail
- Select a template other than "plain text".
- Triple click on a block
=> The tootlip is displayed way too high.
[this commit]: https://github.com/odoo/odoo/commit/a50c09e3b432d7601cd0e02cbbfabe24a67ba70f
task-2777738
closesodoo/odoo#111011
X-original-commit: 42d32a4f40d685e10f2ae4bb678df2009cb4bd21
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
Steps to reproduce the bug :
- In Website (edit mode), drag & drop a "text-image" snippet.
- Click on the button.
- Change the size of the button to "small".
- Click outside the button.
- Re-click on the button.
- The size selected in the options is "medium" and not "small".
Note that the same bug exist in backend with the link dialog.
This bug was introduced in ([1]), the code of the "else" (which was
removed by it) made it possible to take into account the cases where the
option had no "value" (e.g. "medium" size button). And so, without this
"else", the options without "value" were activated in any case.
This previous commit, which fixed an issue with the presence of the
"btn-success" class on a link, could in fact be based on what had
already been done for the links with the "btn-link" class (in [2]).
In this commit, this issue with the "btn-success" class is handled the
same way as for "btn-link".
[1]: https://github.com/odoo/odoo/commit/4c68b3e923610e1d573b4bd2b241b2fc5923c412
[2]: https://github.com/odoo/odoo/commit/c3e08e7a7baab1035c3d5c48d668cc02a232e1ac
task-3002177
closesodoo/odoo#110809
X-original-commit: 5e98953d67042dcffa978ab7d240d8677e847456
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
When inserting a backtick in text that has another backtick before
(case 1) or after (case 2) it, we convert the text contained between
said backticks into inline code. Case 2 was not tested, and didn't work
properly.
closesodoo/odoo#110784
X-original-commit: cc2a4a960d6d83362e35abc8a253e95105fd07f9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Wrong syntax made it so that having a text node after the text node in
which we're inserting a closing backtick character, converted all the
text after the backtick to the word "NaN". This fixes that syntax error
and ensures such cases are properly handled.
X-original-commit: 2833b42c09582dbcfed334d9fe6628a8eaf476b8
Part-of: odoo/odoo#110784
Before this commit, this flow was broken:
- Install website
- Create a new website of your own (not using the one created
automatically from XML data)
- Choose another color palette for that website
- Uninstall the website app
- Reinstall the website app
- Try to choose another color palette for any website
=> It does not work
Indeed, after the uninstallation, the DB is left in an invalid state:
the SCSS customizations attachments of the website that was created by
the user are not removed, they just have their website_id field emptied.
Some code made at [1] was already there to remove those attachments. The
problem is that it only worked for websites which were created by XML
data (at website installation), not by the user. Indeed, the `unlink`
method is not called during uninstallation to remove records that were
created by the user, thus the `unlink` override was not called either.
See [2] for some details.
This fixes the issues by moving this attachment cleaning code in a
dedicated method, called in `unlink` but also in the `uninstall_hook` of
the website app.
This also takes the opportunity to refactor the code involved, in
particular to not even consider customized attachments which do not have
a website_id.
[1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1
[2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656
opw-3127531
closesodoo/odoo#110338
X-original-commit: 988eafa03b57be3b3a7f110650c61ce8fda88e31
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the only change in a form was made in the html editor, if the user
did not blur the editor, the content was not saved.
The reason is because the `urgentSave` in `basic_relational_model.js`
check if the record is dirty before the HtmlField had the time to update
the value to make it dirty since the commitChange in the HtmlField could
run promises before calling `update`.
To solve it, in case of urgent save, we update the value before any
asynchronous modification and re-update it after those modifications.
In order to have this strategy only on urgentSave and not on the
blur of the editor, the params `{urgent: true}` has been removed in
`_onWysiwygBlur` as it seems to not be useful. Another params will need
to be added if we want to keep that behavior on blur.
task-3140763
closesodoo/odoo#110517
X-original-commit: 3ff0d4b032e44719f52d09c7bfb701c47a79a5c3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
When entering edit mode on the website and discarding directly, the editor
considers that there are changes in the DOM and displays a confirmation modal.
After this commit:
When entering edit mode on the website and clicking directly on discard, the
confirmation modal is not displayed.
Task-3056463
closesodoo/odoo#110515
X-original-commit: 650a97d1bd59254cc2115d54d58940b6112a8d70
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Dhaval Baraiya <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Before this commit, it was possible to edit void element if they were
branded. It does not make sense to edit a void element.
task-3096813
X-original-commit: fbf633b8110a74dbf25bdc5372a60e793017fbdc
Part-of: odoo/odoo#110513
In the web editor when the placeholder using the class `oe-hint` is
shown the insertion caret color is almost invisible in dark-mode.
This commits reset the caret to its default behavior by removing the
`caret-color` property from the class `oe-hint`. Therefore making the
caret dark in white mode and white in dark mode even when the
placeholder is shown.
It makes it consistent with all the other inputs w/ a placeholder.
task-3099628
closesodoo/odoo#110477
X-original-commit: 4caf4eb9b957853245a881b645863d6af8a166d1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce the bug :
- In website (edit mode), add a mega menu in the Header.
- Choose the "Cards" template for the mega menu.
- Click on a card of the mega menu.
- Change the url of link in the editor panel toolbar.
- The style of the card is broken.
The issue is that when the link of the card is changed, 2 classes are
removed from the link ('text-wrap' and 'text-center').
This is from code that removes all classes starting with "text-" and
"btn-" when updating the link in the DOM. This commit fixes that by
avoiding removing classes that should never be removed there.
Note that a previous commit ([1]) had already corrected this but only
for the "btn-block" class. This commit fixes the issue in a more generic
way.
[1]: https://github.com/odoo/odoo/commit/888687b487e95b4bf4fb080118b5eb945c8ab724
opw-2954714
task-3006845
closesodoo/odoo#110186
X-original-commit: 121af26cfee8a227ce5925d3a64a99c5bb63d35f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since the migration to Bootstrap 5 (at [1]), the tooltip for the
background position overlay was no longer disposed when toggling the
overlay back on.
This meant that new tooltips kept being added and could lead to a very
confusing user interface.
This was fixed for legacy widgets at [2] but the tooltip for the overlay
is a specific case.
This commit makes disabling the overlay also dispose of the tooltip.
Steps to reproduce:
- Edit a website and drop a cover snippet
- Toggle the background position overlay (by clicking on the target
icon)
- Close the overlay (discard, save or click on the editor)
- Change the Parallax option from fixed to Top to Bottom (this is just
so that the previous tooltip is clearly visible after the next step)
- Toggle the background overlay again
=> The old tooltip is still present and a new one is visible
[1]: https://github.com/odoo/odoo/commit/1fcd098af5fa18e848c66bb83bdceb6ba0308512
[2]: https://github.com/odoo/odoo/commit/3c01b1cd77adec146b1a90f96bb1223a2108678b
task-3119958
closesodoo/odoo#110170
X-original-commit: 2ddffeef579baf47ff117b133a9d4fbf12108a2c
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit:
On removing link, all classes were removed including non-button link classes.
After this commit:
Only remove link related classes and remaining classes are preserved by
creating span.
Task-2930767
closesodoo/odoo#103602closesodoo/odoo#110169
X-original-commit: 0057b7983b5da42328187f42729b6648002fb2be
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
* = digest, hw_posbox_homepage, im_livechat, mass_mailing, web_editor,
website, website_slides_forum
Since the migration of Bootstrap 5 [1], some CSS rules was automatically
converted (`border-left` and `border-right`) when it shouldn't be.
These conversions were made because the CSS rules was embedded in
HTML/XML code and the REGEX for the conversion had no protection for
these cases.
This commit restores the old correct value.
Ref:
[1] odoo/odoo@1fcd098af5closesodoo/odoo#110141
X-original-commit: 0cbf7c00ecc307fc725da345415647828e771bb4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This behavior only made sense with [1] applying in all cases, but
since it was wrong to begin with (because of the "Plain Text"
template) and was reverted in the previous commit of this PR, then
the behavior does not make sense anymore, as the dialog would open
as soon as the user clicks on the link.
This reverts commit aaf70d3692.
Task-3128388
Task-2889670
[1] https://github.com/odoo/odoo/commit/61f7366d686b353ae9614285370e952253ec067c
X-original-commit: 33e5dcdb41ae2d4bb2a47ea3fd92f522b09b53e8
Part-of: odoo/odoo#110089
Sometimes, there is a crash when uploading a file when loading an article for
the first time.
Impacted versions:
16.0+
How to reproduce:
- open the odoo home page (module menu) and CTRL+f5 (force reload)
- go to the knowledge app
- in an article, put the cursor somewhere and type ENTER to create a new line
- type the /file command in that line
- try to upload a file
- traceback (if it does not happen, try again from the first step, it is not
always consistent)
Fix:
Delay the _onBlur handling of the wysiwig when using the modal. The Blur event
may occur and may trigger an update on the html_field, which may in turn induce
a rerendering of the component and its value.
We don't want this to occur when using the modal, because the selection was
registered by the modal to restore it when the modal closes (`preserveCursor`).
If the contents of the html_field are updated, then the stored position used to
restore the selection won't be in the DOM anymore, and the restoration will
fail. As such when we try to insert the Knowledge file block, the selection is
not in the editor and the method fails.
Task-2889670
Task-3128388
Task-3086694
X-original-commit: 2591d343793f59e2e70e7ffe8fa666661995348f
Part-of: odoo/odoo#110089
Co-authored-by: Antoine Guenet <age@odoo.com>
Both `allow_command_video` and `allow_command_image` options are supported by the
editor, but only `allow_command_video` was being sourced from the XML of the view.
This works:
<field name="body" widget="html" options="{'allow_command_video: false}"/>
But this didn't work without this commit:
<field name="body" widget="html" options="{'allow_command_image': false}"/>
It looks like that particular option was simply forgotten. This commit rectifies that.
Impacted version:
- 16.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#110088
X-original-commit: c81c5918e6ba2f263e173b27978194de1f71f1db
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Commit [1] correctly disabled some of the behaviors of the editor
that used to modify the selection outside of the editable. However,
it also had the inadvertent side-effect of disabling the toolbar
update mechanism when clicking outside of the editable.
Behavior before this commit:
When the toolbar is visible, clicking outside the editable zone
does not hide the toolbar.
Behavior after this commit:
Clicking outside of the editable zone hides the toolbar.
[1]: 07a1483967
task-3131435
closesodoo/odoo#110044
X-original-commit: 28a35a6b53493abd03e42cc30d164262c86b6de5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
Selecting some text and changing its size will never allow you to select 13 and
selecting default will make the text bigger than the surrounding text.
Example in project: the default size is 13px (the editor parses that info and
display 13px as the font-size), but if you want to set any text to that value
you can't. Users could set any text to that value by selecting
"default" font-size instead of 13
After this commit:
"default" sets to "font-size: medium", which is often not correct. It should
instead, do a "font-size: inherit" so that it's the default for the current
context. Hence, removed that medium font-size rule and let the cascade do it.
Task-3095887
closesodoo/odoo#109835
X-original-commit: 9878579f62b493958bb6a98e2cdc466bfc2954d8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue # 1:
Before this commit, copying an empty selection (collapsed range)
produced a Traceback. Making onClipboardCopy return when the selected
range is empty serve as double purpose: avoid that trace and not
overwrite clipboard content with an empty string (leaving the
previously copied content available for pasting).
Issue # 2:
Before this commit, copying a selection that spans over two or more lines
was producing a text/plain content without line breaks. This happened
because the text was obtained getting the innerText property of a detached
element (thus, not being rendered). In such case, the returned value is
the same as textContent, which just concatenates the text content of
text nodes (thus ignoring BR elements). Selection.toString(), for
instance, represents line breaks in the selection as '\n' in the
resulting string.
This commit also removes 2 harmless but useless lines:
if (!clipboardEvent.clipboardData.getData('text/plain'))
if (!clipboardEvent.clipboardData.getData('text/html'))
A copy event handler cannot read the clipboard data.
(see https://developer.mozilla.org/en-US/docs/Web/API/Element/copy_event)
The expressions in the if-conditions above always return true,
as getData will return an empty string.
Finally, this commit also adds basic unit tests for copying and cutting that
were missing.
task-3114102
closesodoo/odoo#109757
X-original-commit: 3a4be5116c23e12129d6e8c9d841a17a57a710a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since its introduction with [1], there is an issue about the full link
URL which is never set.
The preview has 2 URL elements:
- The main one, for which the text will either be the URL itself for
external website or the page title for internal pages.
- The "full one", which will simply be the full URL for internal pages.
It's basically the text of the "main one" which is moved here when
there is a title to display.
But the "full one"'s url was never set, always being "#", meaning that
when you click on the title you land on the correct page but when you
click on the URL itself you don't go to that page.
[1]: https://github.com/odoo/odoo/commit/8fcf930a6b6b7ffb0965b0a689c7a3117962ce7e
task-3129267
closesodoo/odoo#109716
X-original-commit: 015c9bf111899b2a86c39b24cd1ec2d4e5278204
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, cut/copy operation in non-html fields will trigger the _onClipboardCut/_onClipboardCopy handler as long as there is html field in the same form view.
This will cause cut/copy fail when using chrome or edge.
Only bind cut/copy event to html field as these event handlers are not related to non-html fields.
closesodoo/odoo#109624
X-original-commit: 494f8300f848cf258ba8ba0132af104346083b3e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit when a color was applied on a text that spans several
nodes, it was wrapping each text node in a font node to which the color
was applied. Because of this, applied gradient colors were restarting on
each text part. (e.g. before a bold section, on the bold section, after
the bold section: each had a distinctly drawn gradient)
After this commit the bold and italic nodes are considered similar to
text nodes and are wrapped inside a common font node to which the color
is applied - using the mechanism that already existed for text nodes.
Actually applied on all visible inline & inline-block elements that do
not contain a font node (and are not buttons).
task-2666200
closesodoo/odoo#109537
X-original-commit: 8c965cad4d3fdbfefbbd5caa43d8c21e3a8e064f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [1] the gradient text image was reset within each font or span
block (e.g. for applying bold style).
The change was done because Chrome does not inherit the involved styles
when a transform is used, which is the case in animated texts.
After this commit the inherit style is only applied on animated texts.
This lets the gradient span across style changes.
Note that there is no solution yet for animated texts: they still have
a restarted gradient.
Steps to reproduce:
- Drop a Title block in a website page.
- Add a few words.
- Select the whole title's text.
- Make its text color a gradient. (Not the background color)
- Select the second word (avoid picking the word in the middle to
easily see the visual impact).
- Make that word bold.
=> The gradient restarts within the bold word instead of continuing
across the whole text - even though no text animation is used.
[1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e
task-2666200
X-original-commit: 372eeebb47b93890d567185879981e817cdc1326
Part-of: odoo/odoo#109537
Since [1] when the m2m widget was introduced, when the network latency
is high enough, the `_search()` method can be called several times in
parallel. The former list of existing records is removed before doing
the RPC call, then populated with the results received after the RPC
call returns. With the proper timing and race conditions, this could
lead to having the list cleared several times, then populated several
times with the incoming results.
This commit makes sure the list is cleared after the RPC results are
obtained instead of before.
Steps to reproduce:
- Create and save a blog post with several tags.
- Edit blog post.
- Configure network latency to one second in browser's developer tools.
- Remove one tag.
- Remove another tag after 500ms. (Because the search happens after a
`setTimeout`.)
- Open tag suggestions.
=> List contained the concatenation of the two suggestion lists.
[1]: https://github.com/odoo/odoo/commit/be05ac7e2b8d866a72693b761f3bc8576d54e59e
task-2811746
closesodoo/odoo#109479
X-original-commit: 48564abe484f61c09ca98c3cddd5b4b0b55e6497
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Antoine Guenet