Bug Hunting Session
Bug 34987 - Impress disregards Master Slide setting of text area
Summary: Impress disregards Master Slide setting of text area
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.2.0 target:4.1.3 target:4.0.6
Keywords: regression
: 53340 54005 55720 57152 69108 71223 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2011-03-03 14:22 UTC by Christopher M. Penalver
Modified: 2013-11-24 15:19 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher M. Penalver 2011-03-03 14:22:23 UTC
Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/641175

1) lsb_release -rd
Description: Ubuntu Natty (development branch)
Release: 11.04

2) apt-cache policy libreoffice-impress
libreoffice-impress:
  Installed: 1:3.3.1-1ubuntu4
  Candidate: 1:3.3.1-1ubuntu4
  Version table:
 *** 1:3.3.1-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status

3) What is expected to happen is when one performs at the Terminal:

loimpress -nologo

click Next button -> Next Button -> Create Button -> View -> Master -> Slide
Master -> Format -> Page... -> In Page Setup window (notice Orientation has
highlighted Landscape radio button) Width 5.51" -> Height 2.68" -> Ok button
-> In Master View window Close Master View -> Insert -> Slide -> File -> Save
As... -> Name example -> File Type ODF Presentation odp -> Save button -> File
-> Exit -> Perform at the Terminal:

loimpress -nologo example.odp

Insert -> Slide
The new page has the same configuration as the Master Slide.

4) What happens instead is now the box extends downwards vertically below the Master Slide settings.
Comment 1 Don't use this account, use tml@iki.fi 2011-03-04 03:43:21 UTC
For Thorsten?
Comment 2 fmjrey 2011-03-08 09:59:27 UTC
Also having this issue with lo3.3.1 on ubuntu 32 bit.
When closing/reopening the document the master page content zone kept setting itself to adjust with text.
It made master slide unusable in my use case, so I had to install oo3.3 instead to continue working.
Comment 3 fmjrey 2011-04-04 09:57:07 UTC
Could anyone have a look as this issue?
This prevents me from using libreoffice, so still on oo3.3.
I'm setting Importance to Normal instead of minor: loosing settings when saving is not a minor issue, data is lost!
Thanks
Comment 4 Christopher M. Penalver 2011-04-04 21:08:37 UTC
fmjrey, this issue is currently assigned to tbehrens@novell.com. If you want to collaborate on development feel free to shoot an E-Mail. Issue confirmed in Ubuntu 10.10, LibreOffice Impress 3.3.2.

lsb_release -rd
Description:	Ubuntu 10.10
Release:	10.10

apt-cache policy libreoffice-impress
libreoffice-impress:
  Installed: 1:3.3.2-1ubuntu2~maverick1
  Candidate: 1:3.3.2-1ubuntu2~maverick1
  Version table:
 *** 1:3.3.2-1ubuntu2~maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status
Comment 5 fmjrey 2011-05-29 07:01:14 UTC
Changing from medium normal to high major because this bug:
- causes data loss: settings from master slide are not saved
- causes the loss of a major functionality: master slide cannot be changed
Would be great if this bug could get the attention it deserves.
Thanks.
Comment 6 voltaic 2011-09-24 13:18:07 UTC
I'd like to confirm that this bug is still present in 3.4.3. I cannot alter existing master slides at all. This makes it cumbersone to create new Impress presentations from scratch.
Comment 7 MrBrownwait 2012-05-31 10:22:21 UTC
I have got nearly the same bug on my system (Fedora 16 x86_64) but the box is not getting too big but too small.
Changing system to all
Changing version to LibO 3.4.5 release.

Thank you
Comment 8 voltaic 2012-10-22 23:18:58 UTC
The issue persists in LibreOffice 3.6.2.2.

Please note that there have been several duplicate reports in recent months. I don't have permission to mark them as duplicates, so I will list them here:

Bug 55720, 53340, and 54005.

I will note this on the duplicated reports, but ultimately someone should merge the above.
Comment 9 Christopher M. Penalver 2012-10-23 03:18:04 UTC
voltaic, please do not toggle the Version. For more on this, please see http://wiki.documentfoundation.org/BugReport_Details#Version .
Comment 10 Jorendc 2013-01-29 22:44:40 UTC
*** Bug 55720 has been marked as a duplicate of this bug. ***
Comment 11 Jorendc 2013-01-29 22:44:55 UTC
*** Bug 54005 has been marked as a duplicate of this bug. ***
Comment 12 Jorendc 2013-01-29 22:45:58 UTC
*** Bug 53340 has been marked as a duplicate of this bug. ***
Comment 13 Christopher M. Penalver 2013-01-30 01:59:06 UTC
Reproducible in:
Microsoft Windows Vista Business x86 6.0.6002 Service Pack 2 Build 6002
Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)
Comment 14 bugquestcontri 2013-02-06 09:07:46 UTC
Just made a test. The problem reported in 
https://bugs.freedesktop.org/show_bug.cgi?id=55720
still exists in LibO Version 3.6.5.2 (Build ID: 5b93205) on XP/SP3.
Comment 15 Joel Madero 2013-02-11 16:01:46 UTC
As this bug has been confirmed to be in LibreOffice 4 as well, going to move forward with making this a MAB3.6. 

3.5 is at end of life in its cycle and therefore will get no more updates. We are trying to close the 3.5 most annoying meta bug.

In general I wouldn't agree that this is a MAB as it just doesn't affect enough people BUT since it's been on the list for nearly a year I'll go ahead and push it forward to the 3.6 MAB list. We'll try to push this one forward ASAP.

Thanks for your patience, apologies it's taken so long
Comment 16 bugquestcontri 2013-02-12 04:16:46 UTC
Thanks for pushing it forward. This bug is always cumbersome because it slows people down.
Comment 17 mhofmann 2013-03-22 07:53:03 UTC
I will investigate the bug.
Comment 18 Jacqueline Rahemipour 2013-03-23 18:52:00 UTC
It seems, that the changes in the master slide are stored correctly in the styles.xml, but they are not visible after saving and reopening the file.
Comment 19 Jacqueline Rahemipour 2013-03-23 20:47:18 UTC
*** Bug 57152 has been marked as a duplicate of this bug. ***
Comment 20 Michael Meeks 2013-03-26 16:21:08 UTC
I had a recollection that you did some master-page fixing recently David - was this a duplicate ? :-)
Comment 21 mhofmann 2013-03-26 19:53:48 UTC
Are the fix already pushed to master? With a build from monday I can still reproduce the bug.
Comment 22 Joel Madero 2013-03-26 20:04:08 UTC
As far as I can tell there is no fix yet. You'll see an automated message when the fix is committed to master
Comment 23 mhofmann 2013-04-29 18:22:09 UTC
The cause for this bug lays in following method (xmloff/source/draw/ximpstyl.cxx):
void SdXMLMasterPageContext::EndElement()

It gets called when the XML element "style:master-page" in styles.xml is closed. That means that the master page is completely parsed. In the EndElement method ((SdXMLStylesContext*)pContext)->SetMasterPageStyles(*this); is used to set all default styles for the master page. The problem is that all user modifications are already applied and are overwritten with this call.

A near idea is to set the default styles when creating the master page and than apply all customizations. So I moved the SetMasterPageStyles call to the constructor of the SdXMLMasterPageContext class (entering of the XML element "style:master-page"). This solves the problem with the size of the outline object, but it breaks the font. The size of the font used in the master page are not set correctly.

My knowledge about libreoffice is too limited, to distinguish if I fall from one bug into another one, or if this behaviour is reasonable.

Any hints/feedback how to handle this bug is welcome ;)
Comment 24 mhofmann 2013-05-07 15:42:52 UTC
My knowledge about libreoffice is too limited to fix this bug. Every approach I tried break some other stuff, so feel free to grab this bug.
Comment 25 bfoman (inactive) 2013-05-16 13:06:39 UTC
Joel: Assumming that nobody is actually working on it or has any
plans to do it soon (see comment 24) are you willing to change status of this bug back to NEW?
Comment 26 tommy27 2013-08-08 09:10:46 UTC
I cannot test to reproduce this bug. So I ask the original reporter if he still experience it on recent LibO versions like 4.0.4 and 4.1.0
Comment 27 mhofmann 2013-08-08 17:30:44 UTC
The bug exists still in LibO 4.1.0.4 (tested on windows 7)

Just open a new presentation, change the slide size to A6 and save the document. Now close the document and open it again. When you now create a new slide the text box is too big. Or just look at the master slide ;)
Comment 28 tommy27 2013-08-08 18:14:27 UTC
@mohofmann
thanks for your confirmation. 
I'm gonna move this from mab3.6 to mab4.0 since 3.6.x branch is no longer supported.
Comment 29 Jozef Mlich 2013-08-09 07:40:05 UTC
The bug still occurs at Libreoffice 4.1.0.3-2.fc19
Comment 30 Caolán McNamara 2013-09-06 14:43:36 UTC
This was triggered by http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa9af08b389a106fcfb53842ac7669b208a27205 specifically the sd/source/core/stlpool.cxx rSet.Put( SdrTextAutoGrowHeightItem(FALSE) ); line which causes the xmloff to call some reset property stuff on import which causes the box to recalculate itself as mhofmann describes
Comment 31 Cor Nouws 2013-09-06 14:54:32 UTC
Did some testing in 4.1.1.2:

One slide
One master slide
Change width of both text boxes is master slide.
Back to normal view.
   > changes not visible.

Create new masters slide also with different width for text boxes
Back to normal view.
Apply MasterPage2
   > changes not visible

However ... the changes do show in the preview of the master slides...

Now add a slide
   > has MasterPage2 applied
Apply first master page
   > Only one of the text boxes is changed

Now add third slide
  > both master pages can be applied there and show all changes

The funny thing is, that for the first and second slide the behaviour is still the same, as described above :D
Comment 32 Federico Kereki 2013-09-08 16:13:36 UTC
This is still happening in the 4.1 release, both for 32- and 64-bit Intel processors.
Comment 33 Federico Kereki 2013-09-08 16:14:49 UTC
This should be considered a really major error -- it's really hard to work with templates if your sizing isn't kept.
Comment 34 Cor Nouws 2013-09-08 18:13:36 UTC
*** Bug 69108 has been marked as a duplicate of this bug. ***
Comment 35 Caolán McNamara 2013-09-09 16:04:04 UTC
https://gerrit.libreoffice.org/#/c/5887/ "works for me(tm)" for the original problem of the initial report.
Comment 36 Commit Notification 2013-09-12 22:21:00 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=14e7a290dab7fead66ef6ff7f94c6a425d80ceb6

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 37 Commit Notification 2013-09-14 13:20:05 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0964a73d03bf9f5b9f485ff39f97c7e7b54339b3&h=libreoffice-4-1

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value


It will be available in LibreOffice 4.1.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 38 Caolán McNamara 2013-09-17 19:33:01 UTC
Fixed in 4-1 and 4-2, proposed in gerrit for 4-0 and 4-1-2
Comment 39 Commit Notification 2013-09-19 19:22:32 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=19a9dda3ec36874d337de65364c265946c7004df&h=libreoffice-4-0

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value


It will be available in LibreOffice 4.0.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 40 sophie 2013-11-05 16:33:28 UTC
*** Bug 71223 has been marked as a duplicate of this bug. ***
Comment 41 bugquestcontri 2013-11-24 15:19:53 UTC
tested in 4.1.3.2 and found the bug is gone.
Thanks to all who worked on the fix!