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>
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.
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.
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 137176 [details]
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
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
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]
Created attachment 140864 [details]
(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!
I can confirm that the bug is present in
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