Build ID: aaca25d67eb5ea252730cdcf555ecc04ce04a5e6
CPU Threads: 2; OS Version: Linux 3.16; UI Render: default;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-24_23:58:47
Locale: en-US (en_US.UTF-8)
1. Write a line in writer;
2. Highlight the line;
3. Change paragraph spacing from sidebar
Observed: Text disappears
Expected: Spacing changes, text remains there
Seems like it always worked this way:
Minor: Can slow down professional quality work but will not prevent (undo possible);
High: Makes the sidebar spacing much less functional + regression + common task
Missed a step in instructions:
1) write a word;
2) highlight word;
3) Put cursor in sidebar paragraph spacing (above or below) input field;
4) change value to 1;
5) push enter
So it seems like Writer is treating it like the cursor is not in the sidebar but instead is just in the document but this isn't the case, the cursor actually is obviously in the sidebar as you can see it blinking in the sidebar so IMHO nothing you do there should be able to completely delete text.
This being said, it's fair for UX to decide, feel free to close if you don't agree.
Confirmed this is a bug that goes all the way to when the sidebar was implemented.
Build ID: ed51d4293dd919a03edca11ec48c607bbfa31076
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default;
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-03-07_00:33:34
Locale: en-US (en_US.UTF-8)
1) Open Writer
2) In sidebar select a combobox (e.g. Styles) or spinbox (e.g. paragraph spacing above) and press enter
3) Notice that you Undo is now enabled in the toolbar and an new line was added in the document
Hmm, Linux only?
Can not confirm. On Windows 8.1 Pro 64-bit en-US with
Build ID: 7ccdb94e2c5774f924bf89b34387c7d41e2e4c30
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL;
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-03_02:40:45
Locale: en-US (en_US)
If I highlight paragraph and in the Sidebar Paragraph spacing--above or below-- enter 1 the spacing becomes 1.00 inch. If entered in both above and below, the two selected one word paragraphs will reformat-- 1.00" above the first, 2.00" separating the two, and 1.00" below the second.
This is behaving as I'd expect--although entering 1 is a rather unuseful value. The spinner widget is increasing and decreasing the values--for me in 2/100" increments. Also, the keyboard <Tab> and <Shift>+<Tab> movement between the button widgets in the content panel seem to be behaving. And <F10>, <F6> for focus navigation back to the document canvas is behaving as well.
(In reply to V Stuart Foote from comment #4)
> Hmm, Linux only?
> Can not confirm. On Windows 8.1 Pro 64-bit en-US with
> Version: 126.96.36.199.alpha0+
> Build ID: 7ccdb94e2c5774f924bf89b34387c7d41e2e4c30
> CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL;
> TinderBox: Win-x86@39, Branch:master, Time: 2016-03-03_02:40:45
> Locale: en-US (en_US)
> If I highlight paragraph and in the Sidebar Paragraph spacing--above or
> below-- enter 1 the spacing becomes 1.00 inch.
Push enter after entering the number 1.
Oops, nevermind. It afflicts Windows builds also.
Just read Jay's note. And, entering "Enter" key while in the Paragraph content panel spacing spinners widgets does have a linkage to the selected text in the canvas. The "Enter" key action "inserts" blank text into what had been highlighted.
The Indent spinner widgets also do the same this of clobbering the selected paragraph with an Enter key press.
** 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!
Related patch by Jim: https://cgit.freedesktop.org/libreoffice/core/commit/?id=bcfc348663b04834fe8e6d6315f647be1595469a
Created attachment 144898 [details]
Please see the video.
In video I higlighted the text, then I changed the space to 1 and press ENTER several times. It seems it works ok.
Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-08_00:00:43
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded