Inside the cell of a table, indenting had several behaviors:
- if the selection is contained in several nodes elements: indent the
element child nodes of common ancestor
- if the selection is contained in one or more list items: indent these
list items
- if the selection is contained in one 'content block': indent the whole
cell content
The two first behaviors are expected, but the third one is a little odd
and unexpected next to other existing editors behaviors.
With this commit, the third behavior becomes:
- if the selection is contained in one `content block`: indent this
content block
note: 'content block' is defined as p, pre, h1, h2, ..., blockquote, td
opw-1824647
closes#24182
Commit cae188514f was largely incomplete
and inaccurate in fixing the issue at hand
The aim of this commit is to deactivate the form buttons when the Html field is not completely loaded
thus preventing the temporary value of the iframe to be saved
OPW 1824545
closes#23905
Before this commit, when a user open an existing link in the editor
he cannot check/uncheck the option "Open in new Window" while he don't
update the url.
The field was hidden while keyup was not called.
After this commit, if the url contains a url, we show directly the checkbox.
This commit fixes opw-1819601
This commit improves link creation in web editor.
Before this commit, anything with a @ would be considered as valid email which
is obviously not the case. It would then be prefixed by 'mailto:'.
This was causing 2 issues:
- URL with @ symbol in it would have 'mailto:' added as prefix, like google
maps coordinates.
eg: mailto:http://www.google.com/maps/whatever/@312211.22,321321
- Incorrect emails would go through (eg: @@@, ko@k@k@, mail@mail)
Now, we will try to detect and identify valid emails from invalid emails from
URLs. It will also handle 'mailto:' directly typed in the input.
This commit comes with it's counterpart in enterprise https://github.com/odoo/enterprise/pull/1859
This closes#11984, closes#22936
Note that there is a WIP in master to use this new is_email function
everywhere we try to validate emails. It will aim to uniformize email
validation in odoo's javascript that are often performed with different mean
here and there, some more permissive than others, some only checking for @.
* web_editor, website
This commit fixes a bug with table duplication in mailing template:
- Click on a snippet with two columns
- Duplicate it
-> the snippet is duplicated but the two columns are transformed in two
rows.
This was because there is an implemented behavior for column
duplication: if we duplicate a column which was alone on its row, we
duplicate the row instead. This code should however be triggered when
duplicating the column alone to be working, not the snippet that
contains it.
Note: this required a backport of a33ec972ab
which was fixing a non-critical "bug" for 11.0. This non-critical "bug" is
therefor fixed here too.
opw-807105
Browsers' default alignement of <td/> is 'inherit'. Some mail clients do
not set this value properly though and even if it is explicitely set,
they do not compute the final value well.
As a fix, this commit forces the 'inherit' value on <td/> and computes
the real alignment for 'inherit' values when transcoding.
opw-813688
On latest chromium (as of version 64), accessing rules of a stylesheet
is forbidden for cross-domain.
This commit catch and ignores the error when that happened.
chromium commit: https://chromium.googlesource.com/chromium/src/+/a4ebe08c91
opw-813480
opw-815860
closes#23009
Deleting/replacing an image through summernote gave unexpected results.
As modifiying the related function may be tricky, this commit instead
wrap them to solve the specific erratic behavior: if the range is in/
matches an image, then simply remove the image and move the cursor to
its previous location.
Before this commit:
When website default lang was not en_US, the translation of fields* in the
web_editor would not be saved correctly.
Let's illustrate with fr_BE set as main lang:
The web_editor's RPC calls does not send language in the context when editing
a page (6ebcc06), but it does in translation mode.
Note that editing is always performed in the website main lang, fr_BE in this
case.
Therefore:
1. When EDITING:
The backend suppose the language is en_US as there is no lang in the
context (hardcoded everywhere).
It then write in the record itself instead of the ir.translation as it
should since fr_BE is a translation. (In Odoo, every lang is a translation,
en_US is always the main lang)
2. When TRANSLATING (in en_US):
It would also write on model as the web_editor send the language to the
backend when in translate mode. But since en_US is recognized as the main
lang (which is correct), it also writes in the model, overriding the
incorrect fr_BE writing which was also wrote on the model.
This has been fixed in 10.0 with these 2 commits:
036ccbe2955bf2
With these fixes, the lang is correctly added (by the backend) if the website
module is installed.
By ensuring the lang is correctly set, the ORM _write() function will process
the edition and translation datas as it should:
- If it receive en_US, it will write on the model
- If it receive another lang, it will write on ir.translation
This closes#10883, closes#22403
*Not the HTML/XML fields which are handled differently by the ORM/translation
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
note: backport of 10.0 13c326caaa
opw-807180
closes#22701
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
opw-807180
closes#22639
When clicking on a link in the editor, the "center" alignment button
was always marked as active whatever the real alignment of the link.
This was because it considered the alignment of the text inside the
link instead of the link's one inside its parent.
$('web_editor.base').ready() returns a deferred that:
- wait at least for $(document).ready()
- wait at least for require('web.ajax').loadXML()
- at most once starts translations configuration
But there is an issue since there is unexpectedly no reference to the
translations, whilst it should have also been ready when ready was
resolved.
This commit keep the reference so translations can be used after
$('web_editor.base').ready() is resolved as it was before 7dfdfa0103.
note: in 11.0 it should be solved with 29729769 (so fix is for [10,11[)
opw-804148
closes#22522
Sometimes the formatting buttons had no effect or formatted more than
they should (like a whole column when triple clicking on a paragraph
only). This was because of the `listBetween` function implementation.
This is supposed to return all the nodes between one element and another
one... but the logic is wrong without saying from which *point* to start
and which *point* to end. For example, when asking the list between an
element and its parent, the result is very wrong as there is no way to
go from the beginning of an element to the beginning of its parent using
the `walkPoint` function as the `listBetween` function is doing.
Ideally, the function should be entirely fixed but this can be tricky.
For now, the function is just extended to allow to specify points
instead of nodes, and those are used by the `formatBlock` function to
solve the current problem.
... hopefully.
This *must* be forward-ported.
Depending on the browser, the triple-click behavior is different. This
is especially problematic on Chrome, where blank characters at the start
of the neighbor of the clicked element are selected.
A weak attempt to solve that was made by commit https://github.com/odoo/odoo/commit/b85bd358234684974f9af63bc5f28cfabb527767
This commit hopes to solve all the issues once and for all by fully
reimplementing the triple-click for all browsers. The concept is simple:
when a triple-click occurs, select the whole *inner* content of the
deepest DOM *element* that was clicked.
For some unknown reasons, the editor sometimes crashes when dropping a
snippet. As a temporary fix, the non-critical line that causes the
problem is try/catch protected by this commit.
Changing the `deleteContents` method of the editor is tricky. This
commit however dares to add a behavior: if the range does not
represent a selection but only the cursor position and is then asked
to delete its content... it should not do anything as nothing is
selected.
Before this commit:
In the web editor, if you double clicked on a video iframe to edit it, it would
open the MediaDialog(media) with the wrong media element.
Media would be ' ' instead of '.media_iframe_video' (which is its grand
parent):
div.media_iframe_video
div.css_editable_mode_display
'& nbsp;'
Then, if you changed the media by another one (Image or Video), the media would
be wrongly inserted into the DOM, in the already existing iframe, eg:
(1) div.media_iframe_video
(2) div.css_editable_mode_display
(3) div.media_iframe_video
(4) div.css_editable_mode_display
(5) ' '
Since the new media (3) is wrongly instered into (2) instead of replacing (1),
the bug it would not be visible on normal mode (you would still see the
old media) because (2) is not displayed on normal mode.
Then on edit mode you would see both media one over the other.
Note: This only happened when you opened MediaDialog thought double click
directly (not 'Edit 'in navbar) and without clicking somewhere else after you
entered edit mode.
Now, if the media has an iframe parent, we use that parent as the correct media
This closes#22109, closes#22179
Courtesy of QSM for the help
Depending on the speed of the runbot, errors may appear if one tries to
use a template that is not yet loaded. Templates are being
loaded and we add new template to read, the ready function does not
take into account new additions.
Avoid texts to be translated twice if some modules have the translated
value corresponding to the English source term.
To reproduce: create a translation for static xml (comment 'openerp-web')
with 'Modifier' translated by 'Tadaaa'. In french context, the 'Edit'
button in forms is translated by 'Tadaaa'.
Don't translate template in web_editor if we are in the backend because
the translations of all the modules have already been loaded and applied.
Summernote uses `document.execCommand` to apply most styles when
editing, leveraging the implementation to the browser.
Summernote is configured to use HTML styling (`'styleWithSpan': false`),
and in this case, browsers such as Firefox use HTML attributes for
styling text align, while Chrome still uses CSS for that. In fact,
`document.execCommand` is browser-inconsistent... but so is the
`styleWithSpan` option. Indeed, setting the option to `true` will make
Firefox use CSS property for alignment too... but not Internet Explorer.
So we might consider changing this option's value but this would not
solve the current problem.
Indeed, any CSS `text-align` style in Firefox takes precedence above
the element's `align` attribute, so when users were trying to align text
on stuff that was pre-aligned, they were unable to do so.
We can better explain the situation with this example:
A user tries to left-align in Firefox a `p.text-center` element, and
produces this:
```html
<p class="text-center" align="left"/>
```
(`align` attribute is ignored because of the `text-center` class)
On Chrome, this would be produced with the same steps:
```html
<p class="text-center" style="text-align:left"/>
```
With this patch, we actually make that HTML look like expected by the
user, no matter the browser he's using, by forcing the editor to use
the text-align CSS property. Note that the implementation is quite
ugly but had to take care of compatibility.
See https://github.com/odoo/odoo/pull/20900
(thanks to @Yajo for original PR)
Before this commit, it was not possible to save a page
containing a snippet with a SVG tag.
To support SVG elements, we need to use 'Element.getAttribute'
and 'Element.setAttribute' as mentionned in the documentation:
https://developer.mozilla.org/en-US/docs/Web/API/Element/className
For more information, see GH-14485
In the case where:
- you are too fast editing a mass mailing, trigger an onchange (e.g. mailing_model) and then save
You can use the edit/save shortcuts to make yourself believe you are Flash Gordon
- your internet is too slow (Down: 4Mb/s, Up: 500kb/s, Latency: 20ms)
Before ths commit, the onchange will return *before* the field (the iframe actually) is loaded.
This onchange contains a signal *in* the body_html of the field to allow communication with the iframe.
If you save before the iframe is loaded, this body_html keyword will be saved.
After this commit we deactivate the save button until the iframe is loaded.
We could have gone for a python user error on the value of the body_html too.
But it would have added a supplementary click and potential reloading
OPW 783616
Nicolas Lempereur