Description: I copy some bullet list content of e.g. indentation depth 4. Then I create a new bullet point – but move it to the first indentation layer. When I then insert the clipboard content, the content gets indented to layer 4 instead of being matched to the first layer. Additionally, if I want to insert the same passage not at the beginning of a new (empty) bullet point, but after some already existing text, the result is corrupted, because the indentation gets destroyed and seemingly tumultuous. I attached an example document, where I marked, what I did, and at which position. Steps to Reproduce: 1. Copy some bullet list content. 2. Create a new bullet point and move the cursor to another indentation layer. 3. Either fill in some text or leave this bullet point text blank. 4. Press <Ctrl + V> Actual Results: A: Bullet point text remained blank before inserting: ⇒ Content is not inserted at the specified layer. B: Bullet point text exists before inserting: ⇒ Content is not fully inserted at the specified layer, some content is inserted at the old layer. Expected Results: I expect that not the absolute layer is saved, but just the relative position. This way, the copied content would fit correctly into the place of the cursor. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 137176 [details] Example
I took a look at your document. I'm not sure for 100%, but I think you have to use a list style in order to get the expected result. Can you try it?
(In reply to Dieter Praas from comment #2) > I took a look at your document. I'm not sure for 100%, but I think you have > to use a list style in order to get the expected result. Can you try it? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Have tried it with a list style, result is the same. What’s the difference between (Shift +) F12 by the way? Isn’t this a somewhat hidden/unmodifyable list style? Why isn’t this directly connected to a list style?
Repro with the document. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: e1fb3d95ac6d58b60448981e82d90621cad7fea5 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on January 7th 2018 Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
I also experienced that headers below a bullet get moved when I move the bullet up/down. Could be ralated, as the environment isn’t correctly determined/differentiated…? Or should I open a new bug report for this?
(In reply to zyklon87 from comment #6) > I also experienced that headers below a bullet get moved when I move the > bullet up/down. > > Could be ralated, as the environment isn’t correctly > determined/differentiated…? Or should I open a new bug report for this? If you can reproduce the problem from scratch with a fresh document, yes, open a new report.
Could you please invest some time into this bug? Today I had to move around several parts of enumerations and that was a pretty horrible experience, because almost everytime I had to fix the indentation afterwards. I use a list style for enumarations and after moving fore example one part around, which contains a heading and a following itemization, the heading got itemized too. Plus I had the problem, that "Ctrl + 0" didn’t work anymore, so the bullet wasn’t removed from the heading when I formatted it as "text body" (what normally works fine). That seems to me, that the whole structure gets corrupted. I attach two screencast, that show you what I mean. Please implement unit tests! As this got worse with releases 5 and 6!
Created attachment 140863 [details] Example 1
Created attachment 140864 [details] Example 2
(In reply to zyklon87 from comment #8) > Could you please invest some time into this bug? ... > Please implement unit tests! As this got worse with releases 5 and 6! Money, money, money! Give it and everything becomes possible.
It’s easy asking for money. But as you might assume, as a private person I’m far from being able to pay developers – but at least I spend quite some time on debugging and programming free software and thus contribute quite a bit to the community. Please instead ask those bigger institutions which use LO in far bigger scale for investment.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I can confirm that the bug is present in Version: 6.2.2.2 Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 1; OS: Linux 5.0; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
This all looks logical to me. If you paste in an empty paragraph, then all the original formatting is applied - like it should (and not other option makes sense here). If you paste at the end of a non-empty paragraph, then the formatting of the original paragraph remains for the first line. (What the user desires in this case will change depending on the content, but the program has to be consistent one way or another, and that decision has already been made long ago.) So the one problem I (almost) see is the last line when pasting into a non-empty paragraph. But the issue here is that you haven't actually copied the full last paragraph, because the selection stops before selecting the complete paragraph. (You would need to select to the beginning of the next paragraph to select absolutely everything, including the end marker. As proof of that, try pasting BEFORE the ... and see what happens.) So this isn't really a bug either. I think your troubles will reduce if you extend your selection to the beginning of the following paragraph. (Ignore the fact that the selection-highlight includes the bullet before "1" - the bullet isn't a character, but just a result of a paragraph setting that turns on numbering.)
The same concerns were raised in bug 90942. *** This bug has been marked as a duplicate of bug 90942 ***