1. Write a line of text with format a:
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):
xxxxxxyyy (yyy is bold, same apperance as in 4.)
xxxxxxyyy (whole text same format as xxxxxxx)
This behavior does not appear by inserting the formatted text at any position bevore end of paragraph.
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This is still an open Problem. Reproduced in 188.8.131.52 on Windows XP 32 bit
*** Bug 61926 has been marked as a duplicate of this bug. ***
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
LibO: 184.108.40.206 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.
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.
** 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)
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
Confirmed for Version: 220.127.116.11
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
OS: Windows 7 Pro SP1 (64 Bit)
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
Build ID: Gentoo official package
Locale: en-US (C)
(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
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.
I apologize for my unhelpful comment.
I can reproduce on LibreOffice 18.104.22.168.alpha0 32 bit
Build ID: 33c57f15501dbd05834cd8844e9124b06536e62c
Windows 10 Ent, 64 bit
*** Bug 60051 has been marked as a duplicate of this bug. ***
*** Bug 116005 has been marked as a duplicate of this bug. ***
*** Bug 124222 has been marked as a duplicate of this bug. ***