| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes #26701
|
|
In firefox, if we have a range on eg.:
`<input type="file">`
and we tabulate to get to it, we have the range over:
`<button type="button" tabindex="0">Browse…</button>`
which seems to be a "virtual" element inside the `<input/>` but this
magic element is "Restricted" and causes error such as:
`Permission denied to access property "nodeName"`
So this fix ignore errors when getting a range from current selection on
keyup.
opw-1819279
closes #24524
|
|
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
|
|
|
|
Before this commit, it was impossible to delete an image which was a
direct child of a table cell using the trash-icon button in the
toolbar.
This commit fixes the behavior by changing the logic quite a lot, so
it is kinda tricky (see https://github.com/odoo/odoo/commit/25849e918651eba080dac3af4e4fcdc8f1280241
for more explaination).
Closes https://github.com/odoo/odoo/issues/22523
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
The previous implementation apparently came from an old version
of summernote (see https://github.com/odoo/odoo/commit/d33086c03fc1a0882be38ae62989b7f72df20d3b).
This commits should improve it to handle all known cases.
See https://github.com/odoo/odoo/issues/20877
|
|
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.
|
|
The feature was introduced and fixed by following commits:
- https://github.com/odoo/odoo/commit/906875fc78cb80f6c3d5f1f14f997008cd406473
- https://github.com/odoo/odoo/commit/76be5eed449c78eaf0b4208c381169132492ab4a
- https://github.com/odoo/odoo/commit/7401807510a103374fa8eb524ae5a5698ae21a39
The feature is however still buggy in lots of cases as it is a bad
heuristic that cannot handle simple pasting cases. The feature was
initially introduced to allow pasting PDF content without having to
remove all the unwanted line breaks this induces. As this feature is
not that important and introduced more bugs than it solved, the feature
is deleted by this commit. If we want that feature again, maybe it is
worth considering an "Import from PDF" button or something like that.
See https://github.com/odoo/odoo/issues/15665
|
|
|
|
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)
|
|
|
|
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
|
|
There is some odd behavior especially inside a editable containing
newlines.
For example in the sale description on an ecommerce item, lines could
contain newline (it is editable from backend) but as an effect of other
use case, pressing enter could have a range of unwanted side effects:
- removing all the content,
- duplicating the editable (should never happen, if we have one field
"description_sale" we don't want to duplicate it, this has no sense)
In a product name which is in the same use case, there is no newline so
the problem is not apparent, and ENTER do nothing. This is the behavior
we should want in every instance.
If we still want a newline, we have to force it with SHIFT + ENTER key,
also this is regarding field that may or could be present in the backend
views, so it could also be edited in backend.
This change make ENTER ignored when we are editing a node directly child
of an node being edited.
A second part of the issue was that dom.removeBetween (used to remove
content inside a range) could remove the ancestor node that was an
editable. This is not wanted.
For example if we did CTRL + A inside a field with `<br />` then ENTER
or pasting something, the field would be removed and not just emptied
and could not be gotten back without editing the template manually.
This was sometimes mitigated because if a `<br />` was at the end of an
element, it would stay in this use case avoiding the issue.
note: not necessary after saas-16
fixes #17445
opw-751360
closes #19313
|
|
Commit 906875fc78cb80f6c3d5f1f14f997008cd406473 (followed by commit
76be5eed449c78eaf0b4208c381169132492ab4a) tried to tweak to copy/paste
functionality of the editor.
Indeed, in PDF file, when copying a paragraph, a line feed is added at
each forced line break (page width end). This forced a line feed and
a new paragraph in the pasted text. The goal was to get rid of those
useless linebreaks when pasting.
The ideal solution would be to detect that the text was copied from
a PDF but it is not possible. However, this commit improves the
heuristic: if this is not plain text, then nothing is done, the content
is pasted normally. If it is plain text (like when copying from pdf),
then each line break which is surrounded by letters or numbers is
considered an useless line break and replaced by a space. This is
obviously not perfect but the previous implementation was really wrong
(it was removing line breaks which were not preceeded by punctuation in
all cases, which was removing lots of useful line breaks).
Note: this commit also fixes a bug -> text was not able to be pasted
with Internet Explorer.
opw-715920
|
|
|
|
|
|
An italic node would be taken as a basic node containing text and thus
would be merged unexpectedly.
For example with the following content : "<i>hello</i> world" removing a
letter of 'world' would merge the text node with hello making it italic.
opw-703722
|
|
|
|
|
|
|
|
opw-686393
|
|
|
|
When pasting, the paste event is cancelled and done back with the
corrected data.
This works fine on firefox, but this can have unwanted results on other
browser like pasting two times or copying the end of the line at the
beginning.
This commit replace completely the summernote functionality with our
small implementation of pasting corrected text.
closes #14043
opw-690814
|
|
The image icon was not clear enough. The editor bar appears in the
website builder, the mail composer, the forum composer, ... In each
of them, we can both link a picture or a file but a picture makes
more sense in some context and in some other ones not.
This commit solves the problem by changing the icon to fa-file-image-o
which is a mixed of file and image. This also solves the problem of
having two buttons with the image icon in the website builder (indeed
an image icon is also used for the image look button).
|
|
* On firefox, you had to click twice on a link to be able to start
typing text
* When selecting text which contained a <br/>, you were not able to
replacing it correctly (you had to click again before starting typing)
* When replacing a whole paragraph content which was below a title,
the text was not replaced and you had to click again and the title
transformed into a paragraph.
* ...
|
|
|
|
Users copy/past text from various king of document into the editor.
These texts contain useless line breaks that should be removed before
pasting. Also, the editor currently add a paragraph element between
each line.
To correct this behaviour the onPaste callback of the summernote lib
is used. However for some reason, this is triggered after the text
is pasted (we should update and refactor the lib in a better way).
So this commit uses a hack: undo the past thanks to the undo command
then paste the formatted text we want.
|
|
|
|
Before 3959afc the `node` tested would be the selection containing node,
but since then it may have been a `<br/>` which has some damaging
effects: now entering double enter at the end of a list, quote or code
block doesn't end this block.
Testing the use case corrected by 3959afc, the said change seems to have
no effect so this commit reverts it.
opw-667618
|
|
* Adapt DOM selectors
* Refactore dialog XMLs to have odoo styling
* New editor options (background-position, ...)
* Various improvements
|
|
|
|
last char of the last line of the td
|
|
issue: the user select some line and keypress tab without indent, and the button indent doesn't work in table cell
|
|
issue: event does not a global var in firefox, and event is already prevented
|
|
Chrome on windows add few comment tags and insert unwanted span.
|
|
can be raise an exception
|
|
|
|
|
|
Depending of the location where the "Copying" happened, only text/plain
content could be available from the clipboard component.
So if no text/html was retrieved, we should fall back to plain text
pasting.
closes #9787
opw-657137
|
|
Summernote sometimes doesn't take into account HTML comment could be
embedded in the edited content, this can lead to issue since this
situation can happen in Odoo.
This commit patch the "isVisiblePoint" summernote's function to take
care of this issue.
opw-656332
|
|
Issue: click on an image or create a text selection and click on delete, the char after the selection is removed
|
|
|
|
|
