[upstream] Pressing undo in Writer removes text but not formatting

[Miikka-Markus Alhonen]

To reproduce this bug, follow these steps:

1) Create two paragraphs of text, one with font size 14 and the other with size 18.
2) Copy some text from the first paragraph to the end of the second paragraph using Ctrl-C and Ctrl-V.
3) Now press immediately Ctrl-Z for undo.
4) While the cursor is still at the end of the second paragraph, type some new text.

As a user, I would expect the new text to have font size 18, since that’s the size of the text just before the cursor. However, as it appears, the new text gets font size 14 because of the text that was copied from the first paragraph. Thus it seems that Ctrl-Z did not undo the whole copy operation but instead just removed the copied text and left its formatting.

Description: Ubuntu 17.10
Release: 17.10

libreoffice-writer:
  Installed: 1:5.4.6-0ubuntu0.17.10.1
  Candidate: 1:5.4.6-0ubuntu0.17.10.1
  Version table:
 *** 1:5.4.6-0ubuntu0.17.10.1 500
        500 http://mr.archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:5.4.5-0ubuntu0.17.10.5 500
        500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages
     1:5.4.1-0ubuntu1 500
        500 http://mr.archive.ubuntu.com/ubuntu artful/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: libreoffice-writer 1:5.4.6-0ubuntu0.17.10.1
ProcVersionSignature: Ubuntu 4.13.0-41.46-generic 4.13.16
Uname: Linux 4.13.0-41-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.8
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon May 21 17:25:11 2018
InstallationDate: Installed on 2017-02-13 (462 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: Upgraded to artful on 2017-11-05 (196 days ago)

[Fdorg-x-bouspam (fdorg-x-bouspam)]

Example:

1. Write a line of text with format a:

xxxxxx

2. Write another line of text with different format (e.g. bold):

yyy (<= bold)

3. Copy the second text ("yyy", Ctrl+C)

4. Insert at end of paragraph of first line (Ctrl+V):

xxxxxxyyy (yyy is bold)

5. Undo (Ctrl+Z):

xxxxxx (same as 1.)

6. Insert unformatted text at eop of line 1 (Ctrl+Shift+V):

Observed behavior:
xxxxxxyyy (yyy is bold, same apperance as in 4.)

Expected Behavior:
xxxxxxyyy (whole text same format as xxxxxxx)

This behavior does not appear by inserting the formatted text at any position bevore end of paragraph.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Michel Kleidt (kleidt)]

This is still an open Problem. Reproduced in 3.5.4.2 on Windows XP 32 bit

[Jmadero-dev (jmadero-dev)]

*** Bug 61926 has been marked as a duplicate of this bug. ***

[Jmadero-dev (jmadero-dev)]

Changing priority:

Minor - doesn't prevent high quality work, just slows it down a little

Low - default for minor bugs, easy work around, doesn't slow down work that much

[Michel Kleidt (kleidt)]

Confirmed.

LibO: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 (32 bit)
on Win7 Pro SP1 (64 bit)

The problem only occur if the cursor is at the end of a paragraph (end of document, end of a table cell (see #50713), ...) but not in the middle of a text.

And it is very annoying, because you always have to ensure, that you have at least a space after the cursor on paste, or you have to change manually the formating after inserting text with different formatting! So I do not agree with comment 4.

[Jmadero-dev (jmadero-dev)]

In order to be objective we use the priority/severity. You agreed there is a workaround - this means it does not PREVENT high quality work, it may slow it down though - of course it can be very annoying to workaround the problem.

This by definition is a minor bug.

That being said, importance/severity does not play a huge role in if the bug gets fixed. Volunteers accept bugs based on what interests them, so don't think the "minor" tag is going to prevent the issue from being resolved.

[Qa-admin-q (qa-admin-q)]

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT:

- Update the version field
- Reply via email (please reply directly on the bug tracker)
- Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword

Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17

[Michel Kleidt (kleidt)]

Confirmed for Version: 5.0.4.2
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
OS: Windows 7 Pro SP1 (64 Bit)

[Jesnow (jesnow)]

Confirmed. Gentoo Linux

This is a STUPID bug because it faces directly toward the user and does something illogical, that is: Undo should UNDO including resetting the current formatting settings, style etc back to what they were. This kind of bug, rather than being a special case rarely seen by anybody, is a symptom of the larger kind of fit and finish problems that plague LO and FOSS generally.

jesnow@Merckx ~ $ uname -a
Linux Merckx 3.18.9-gentoo #3 SMP PREEMPT Mon Sep 7 17:39:42 CDT 2015 i686 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz GenuineIntel GNU/Linux

Version: 5.0.3.2
Build ID: Gentoo official package
Locale: en-US (C)

[Jmadero-dev (jmadero-dev)]

(In reply to Jonatham E. Snow from comment #9)
> Confirmed. Gentoo Linux
>
> This is a STUPID bug because it faces directly toward the user and does
> something illogical, that is: Undo should UNDO including resetting the
> current formatting settings, style etc back to what they were. This kind of
> bug, rather than being a special case rarely seen by anybody, is a symptom
> of the larger kind of fit and finish problems that plague LO and FOSS
> generally.

Vast majority of this statement is completely irrelevant to the issue at hand, it won't push the bug fix forward faster. This is a volunteer project - if a volunteer wants to fix it, they will do so. Until then, the bug will stay (unless you fix it, or you pay to have it fixed).

Thanks for confirming it's still present.

[Jesnow (jesnow)]

I apologize for my unhelpful comment.

[Nagy-akos (nagy-akos)]

I can reproduce on LibreOffice 5.3.0.0.alpha0 32 bit
Build ID: 33c57f15501dbd05834cd8844e9124b06536e62c
Windows 10 Ent, 64 bit

[Beluga (beluga)]

*** Bug 60051 has been marked as a duplicate of this bug. ***

[timur (ba.timur)]

*** Bug 116005 has been marked as a duplicate of this bug. ***

[Olivier Tilloy (osomon)]

Sorry for the lack of feedback until now, Miikka.
I can reliably reproduce the issue with libreoffice 6.0.3.2 on Ubuntu 18.04 and libreoffice 6.1.0.3 installed as a snap.

This is a known upstream bug: https://bugs.documentfoundation.org/show_bug.cgi?id=36958.

[Beluga (beluga)]

*** Bug 124222 has been marked as a duplicate of this bug. ***

[Tcl-de (tcl-de)]

I can still reproduce this in
Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
on Windows 10

[Telesto (telesto)]

*** Bug 132889 has been marked as a duplicate of this bug. ***