Description: Trying to use "Bullets and Numbering > Customise > Character" dialogue to change the font of bullet characters in Impress presentations can trigger multiple buggy behaviours. See below for steps to reproduce. Steps to Reproduce: 1. Create new Impress presentation with "File>New>Presentation". Select the "Blue Curve" template from the chooser. Click Open. 2. Select "View>Master Slide". 3. Place the cursor in the text "Second Outline level" on the displayed Master Slide and right click to select "Bullets and Numbering". 4. Select "Customise" in the "Bullets and Numbering" dialogue. Select Level 1 in the selector on the left. 5. Click on the "Character: Select ..." button. Observe that the "OK" button in the resulting "Special Characters" dialogue box is deactived (greyed out). At this point we can trigger several different buggy behaviours: 6.1 At the bottom of the Special Characters window is an array of "Favourite Characters". Double-clicking on any of these causes that character to (incorrectly) appear on the master slide at the insertion point. 6.2 Alternatively, use the "Font:" pull-down at the top of the dialogue box to change the font of the bullet character. Two bugs manifest themselves: 6.2.1 If the new font has the desired Code Point, and despite the preview correctly showing the bullet character in the new font, the "OK" button incorrectly remains deactivated (greyed out), preventing the new font being selected. One must pointlessly click on the already-highlighted symbol in the selection grid to activate the "OK" button. 6.2.2 If the new font does not have the desired Code Point, the character selection grid appears to scroll at random. There is no other indication that the character is not selectable in that font. If the "OK" button was active before, it (incorrectly) remains active. Clicking on OK *DOES* cause the bullet character to change - but I can't work out to what font. Buggy behaviours 6.1, 6.2.1 and 6.2.2 are in Version: 6.0.1.1 (Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6) running under MacOS 10.11.6 LO 4.0.6.2 and 3.3.0.4 do not have the "Favourite Characters" feature, so do not exhibit bug 6.1. LO 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24), running under 10.11.6 exhibits behaviour 6.2.1 the first time the Special Characters window is opened in a particular run of the program, but then not subsequently. LO 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24), running under 10.11.6 seems to exhibit behaviour 6.2.2. Actual Results: See "Steps to Reproduce". Expected Results: See "Steps to Reproduce". Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.0.1.1 Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-GB (en.UTF-8); Calc: group User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:58.0) Gecko/20100101 Firefox/58.0
I can reproduce the described behavior using Version: 6.0.1.1 (x64) Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (de_DE); Calc: CL 6.2.1 is no problem for me. 6.1 and 6.2.2 are indeed strange and needs improvement. But I don't know, whether the problems can be handled together.
I can confirm all of these behaviours with Version: 6.0.1.1 Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
Followed the "Steps to reproduce" with: Version: 6.1.0.0.beta1 Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-US (en.UTF-8); Calc: group Result: Behaviour 6.1 is NOW FIXED. Behaviour 6.2.1 is still present. Behaviour 6.2.2 is still present.
(In reply to Andrew Watson from comment #3) > Followed the "Steps to reproduce" with: > > Version: 6.1.0.0.beta1 > Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 > CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; > Locale: en-US (en.UTF-8); Calc: group > > Result: > > Behaviour 6.1 is NOW FIXED. > > Behaviour 6.2.1 is still present. > > Behaviour 6.2.2 is still present. I don't understand... So, it's fixed in 6.1 but not in 6.2 ? did you mean 6.0.1 and 6.0.2 instead? Could you please paste the info from Help - About LibreOffice?
I followed the original "Steps to Reproduce" with exactly one version of LibreOffice - this Beta version of LO 6.1: Version: 6.1.0.0.beta1 Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-US (en.UTF-8); Calc: group I did not test against any other LO version (i.e. I did NOT test against any version of LO 6.2). In the original "Steps to Reproduce", step 6 is subdivided into sub-sections. Step 6.1 shows how to trigger one bug, step 6.2.1 shows how to trigger a second bug, and step 6.2.2 shows how to trigger a third bug. Under the version of 6.1beta1 that I tried, Step 6.1 in the "Steps to Reproduce" no longer triggers a bug. However, Step 6.2.1 and Step 6.2.2 still result in the same buggy behaviour as before. (The source of the confusion is that the latest LO beta version is 6.1, but the "Steps to reproduce" also has a step 6.1 - next time I'll label the sub-steps 6a, 6b, 6c etc :-).
Followed the "Steps to reproduce" with: Version: 6.3.0.0.alpha0+ Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35 Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded At step 3, the right click menu no longer has a "Bullets and Numbering" item. Instead, replace step 3 by: 3a. Place the cursor in the text "Second Outline level" on the displayed Master Slide and select "Format>Bullets and Numbering" from the menu bar. Result: Behaviour 6.1 is FIXED. Behaviour 6.2.1 is still present. If I change font and the previously-selected Code Point is available in this font, if the "OK" button was previously inactive it remains inactive, and I must pointlessly click again on the selected character to activate the "OK" button to use that Code Point in that font. Behaviour 6.2.2 is partly fixed - if the selected font doesn't contain the desired Code Point, the character box on the right remains blank, and the message "Missing character" is displayed underneath. However, if the "OK" button was previously active then it remains so, and can be pressed, which dismisses the dialogue box. It seems that this always causes the SPACE Code Point in that font to be selected. Surely it would be more appropriate for the "OK" button never to be active if the previously-selected Code Point is not available in this font?
Followed the "Steps to reproduce" with: Version: 6.4.0.0.alpha1 Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded At step 3, the right click menu once again has a "Bullets and Numbering" item, so the "Steps to reproduce" can be followed as originally written. Results are as for 6.3.0.0.alpha0+ above. Namely: Behaviour 6.1 is STILL FIXED. Behaviour 6.2.1 is still present. If I change font and the previously-selected Code Point is available in this font, if the "OK" button was previously inactive it remains inactive, and I must pointlessly click again on the selected character to activate the "OK" button to use that Code Point in that font. Behaviour 6.2.2 is partly fixed - if the selected font doesn't contain the desired Code Point, the character box on the right remains blank, and the message "Missing character" is displayed underneath. However, if the "OK" button was previously active then it remains so, and can be pressed, which dismisses the dialogue box. It seems that this always causes the SPACE Code Point in that font to be selected. Surely it would be more appropriate for the "OK" button never to be active if the previously-selected Code Point is not available in this font?
Followed the "Steps to reproduce" with: Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded Behaviour 6.2.1 is still present. If I change font and the previously-selected Code Point is available in this font, if the "OK" button was previously inactive it remains inactive, and I must pointlessly click again on the selected character to activate the "OK" button to use that Code Point in that font. Behaviour 6.2.2 is partly fixed - if the selected font doesn't contain the desired Code Point, the character box on the right changes to show a space character in the selected font, and the message "Missing character" is displayed underneath. However, the "Hexadecimal:" and "Decimal:" labels underneath continue to show the Unicode value for the previous character, even though it is not available in this font. If the "OK" button was previously active then it remains so, and can be pressed, which dismisses the dialogue box, and the bullet becomes a space character. Surely it would be more appropriate for the "OK" button never to be active if the previously-selected Code Point is not available in this font? If a "Favourite Character" that is not available in this font is selected, the preview (in some unknown font) and Unicode number for the selected character are shown. If "OK" is pressed, that character (in some unknown font) becomes the bullet character. If "Bullets and Numbering > Select ..." is then re-selected, a random character in the previously-selected font is shown in the dialogue box - NOT the character or font that is actually in use as the bullet character at that point.
Dear Andrew Watson, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug