After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749712 - Undo/Redo in composer doesn't work right
Undo/Redo in composer doesn't work right
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Composer
3.18.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Tomas Popela
Evolution QA team
: 756300 757964 757999 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-05-22 05:25 UTC by Tomas Popela
Modified: 2015-12-11 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Reproducer (1.48 KB, text/html)
2015-05-22 05:25 UTC, Tomas Popela
Details

Description Tomas Popela 2015-05-22 05:25:11 UTC
Created attachment 303797 [details]
Reproducer

Moving from https://bugzilla.redhat.com/show_bug.cgi?id=1206079

Writing following in composer:
aaa<enter>bbb
and pressing Undo will end as:
aa|
bbb
instead of:
aaa
bb| 

Actually it is a WebKit bug. You can try to load the attached HTML in Epiphany (or GtkLauncher/MiniBrowser). The test is successful if the caret is after the number 4 (and fail if after the number 2). The problem here is the Monospace font of size 11 (the default one in gnome-shell and probably other DE as well). If you change the font size in the attachment to different one it will start to work again. As well as if you change the font in Evolution (Preferences/Mail Preferences/Message Display/Fixed Width Font) to different size than 11 it will fix the undo/redo as well.
Comment 1 Dario Lesca 2015-06-14 15:03:57 UTC
In html mode the undo problem occur also if the size of font is != 11

Open new messagge
set edit mode to HTML
write "abc" and press enter
write "def" and press ctrl+z
the 'c' of "abc" is removed and the cursor go to up a line

Evloution 3.16.3
Comment 2 Milan Crha 2015-06-19 11:38:27 UTC
One of the known "good" font sizes is 12 points. It can be that more than just the 11 points fonts are broken.
Comment 3 Dario Lesca 2015-06-20 08:22:30 UTC
Yes, also some other font size != 11 can break the undo of Evo.
Yes a good font is 12, but it's not the default and it's a bit huge in some case.

But, the problem is not the font size but a bug of Evo's Editor.
All other editor (evo-3.14.x, evo-all-previus-version, gedit, geany, libreoffice,ecc.) do not have this problem regardless of font size used.

I'm a user, i'm not a programmer but, IMHO, this bug is very urgent to remove.
Comment 4 Milan Crha 2015-06-22 07:18:43 UTC
(In reply to Dario Lesca from comment #3)
> But, the problem is not the font size but a bug of Evo's Editor.
> All other editor (evo-3.14.x, evo-all-previus-version, gedit, geany,
> libreoffice,ecc.) do not have this problem regardless of font size used.

The difference is the technology being used in the background. Evolution pre-3.16.0 used GtkHTML for the message editor, which had its own issues. Evolution 3.16.0+ uses WebKitGTK+ as its editor and relies on it. Neither gedit, nor geany, nor libreoffice uses WebKitGTK+ as its editor widget.
Comment 5 Jürg Billeter 2015-07-24 20:51:30 UTC
Increasing severity to critical as it can cause data loss.
Comment 6 Tomas Popela 2015-10-13 07:07:03 UTC
*** Bug 756300 has been marked as a duplicate of this bug. ***
Comment 7 Tomas Popela 2015-11-16 13:55:35 UTC
*** Bug 757999 has been marked as a duplicate of this bug. ***
Comment 8 Tomas Popela 2015-11-16 13:55:58 UTC
*** Bug 757964 has been marked as a duplicate of this bug. ***
Comment 9 Tomas Popela 2015-12-11 10:53:38 UTC
Fixed with following commits:

    Bug 749712 - Undo/Redo in composer doesn't work right
    
    Implement the workaround on the Evolution side. The cause of the bug is that
    WebKit is having problems determining the right line height for some fonts and
    font sizes (the right and wrong value differ by 1). To fix this we will add an
    extra one to the final top offset. This is safe to do even for fonts and font
    sizes that don't behave badly as we will still get the right element as we use
    fonts bigger than 1 pixel.

commit 87a27e49205de7ab11de3ad8b979e16f0b460ae7 in the master branch for Evolution 3.19.3+

commit bf36bef77ec998a89f3651d35057dc07742163b2 in the gnome-3-18 branch for Evolution 3.18.3+