1) Open Impress
2) Switch to master slide mode
3) Select title placeholder textbox and change font to italics
4) Notice textbox border and the 'Title Area for AutoLayouts' text are still present
6) Click inside the title textbox and change font to italics
7) Click outside of textbox
8) Notice textbox border and 'Title Area for AutoLayouts' text are now gone
9) Save file, close and reopen
10) Switch to master slide mode
11) textbox border and 'Title Area for AutoLayouts' text still not present
There should never be a situation where the border and placeholder type text should be removed when in master slide mode, and there should never be a situation where the border should be removed when in normal mode. This is bad UX as it makes it difficult to select the textbox.
Build ID: 3287bc2f91438085b7604773d5e0346fc3c3f452
CPU Threads: 2; OS Version: Linux 3.19; UI Render: default;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-09-18_06:17:20
Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Yousuf Philips (jay) from comment #0)
> 6) Click inside the title textbox and change font to italics
> 7) Click outside of textbox
> 8) Notice textbox border and 'Title Area for AutoLayouts' text are now gone
Cannot follow this step. Never seen the title area to disappear, and when I change the font style it remains where it is.
Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default;
Locale: de-DE (en_US.UTF-8)
Version: 188.8.131.52.alpha0+ crashes occasionally, but when I go through the steps it's the same as for fresh.
Created attachment 127631 [details]
Ok, reproduced with 184.108.40.206 / Ubuntu 16.04.
In 220.127.116.11 / Windows 7, I get an extra undo step in the list after clicking outside the frame after the first undo: "Edit text of Title text 'Click to...' "
The 'Title Area for AutoLayouts' and textbox border doesn't disappear after second undo step, though (but then there are two entries in the undo list).
Jay, you mentioned for you it occurs in Windows, too, did you notice extra undo entries?
(In reply to Aron Budea from comment #3)
> Jay, you mentioned for you it occurs in Windows, too, did you notice extra
> undo entries?
I have 1 undo after step 4 and step 7 on my old 08-29 windows build, but with bug 102343 fixed, there is now two undos after step 7 on yesterday's linux build.
** 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've just reproduced this bug with LO 18.104.22.168 using a different set of steps:
1. Select "File>New>Presentation"
2. Hit "Cancel" on "Select a Template" dialogue to get a plain blank presentation.
3. Select "View>Master Slide"
4. Left click in "Click to edit the outline text format" text
5. Right click, select "Edit style..."
6. Under "Font" in the resulting Dialogue Box, change the Font or select Italics. Click "OK".
7. Select "File>Save"
8. Pick any name, press "Save"
At this point the "Object Area for AutoLayouts" label on the slide disappears.
The problem is also in the saved file, as you can verify by closing this copy and opening the saved one.
This problem isn't just cosmetic - at some later point, after further modification and saving/loading, LO can re-create the "Object Area for AutoLayouts" text box, exactly duplicating the content of the existing non-Autolayout text box. I don't have a set of steps to reliably recreate this duplication, but it's happened to me more than once. Any subsequent change to either the unlabelled text box or the AutoLayout box (e.g changing their position or font) does not affect the other one, and LO will not allow either to be deleted. At the very least this makes the master slide look very messy.
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default;
Locale: en-GB (en.UTF-8); Calc: group
In response to Comment 7 (MassPing-UntouchedBug):
"Steps to reproduce" in Comment 6 still provokes the buggy behaviour in:
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx;
Locale: en-GB (en.UTF-8); UI-Language: en-US
(However, with this version I don't seem to be able to reproduce the bug using the "Steps to reproduce" in the orginal bug report).