Download it now!
Bug 70933 - FORMATTING: docx changes certain page format background color upon reopening
Summary: FORMATTING: docx changes certain page format background color upon reopening
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Windows (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: filter:docx
Depends on:
Blocks: DOCX-Page
  Show dependency treegraph
 
Reported: 2013-10-27 20:35 UTC by esafe11
Modified: 2019-07-30 08:30 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
colorPage.odt: 30 pt border, zero page margins (7.75 KB, application/vnd.oasis.opendocument.text)
2018-07-25 12:08 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description esafe11 2013-10-27 20:35:53 UTC
Problem description: docx refuses to keep the background color (changes color back to white). 

Steps to reproduce:
1. open "page" under "format"
2. change all margins to 0
3. click on background tab (then click yes) then click and choose any "obvious it's not white" color.
4. click on the borders tab. click on "set all four borders" box(2nd option under the "default" options)
5. change "spacing to contents" to 1 inch or whatever you like (changing one automatically changes them all).
6. click on ok. save, close, and reopen document.

Current behavior:
changes page/background color back to white.
Expected behavior:
to keep the whole page/background the color i specify.
              
Operating System: Windows 7
Version: unspecified
Comment 1 Joel Madero 2013-10-27 20:54:39 UTC
Please don't add your own bug to the MAB list as it's against policy unless a developer or QA person has asked you to do so. Also the appropriate status is UNCONFIRMED until it's verified by an independent QA person
Comment 2 Joel Madero 2013-10-27 22:19:22 UTC
So it looks like this has been fixed in 4.2 branch - I can confirm on 4.1 branch but 4.2 branch is resolved.

Tested on Ubuntu 13.04


Michael - think we can locate what patch fixed this and backport it to 4.1? Because this is a data loss bug, hopefully we can locate it.
Comment 3 Joel Madero 2013-10-27 22:49:49 UTC
Please also don't push your own bug on the MAB - these policies are in place to prevent people from spamming their own bugs to the list. Please keep all comments on this bug and QA will decide if it should be on MAB list. As a matter of policy, this one will not get on the list as it's fixed in 4.2 so technically it could be set to WORKSFORME - but we are trying to track down the patch so we can backport it
Comment 4 Joel Madero 2013-10-27 22:51:10 UTC
By "please don't push" I mean - please do not leave any comment on the MAB tracker bug - comments on that bug should only be by devs and QA explaining why a bug is added to the list by someone who knows the policies of what constitutes a most annoying bug
Comment 5 esafe11 2013-10-28 01:33:16 UTC
i tested it out on 4.2alpha0+ and the header and footer still reset themselves to white. something i noticed (in 4.2alpha0+): in the "borders" tab the "left" and "right" "spacing to contents" stay as i have set them upon reopening but the "top" and "bottom" change themselves (upon reopening) to "0" AND under the "page" tab the "top" and "bottom" margins change themselves to the numbers that were in the "top" and "bottom" of "spacing to contents".
Comment 6 Joel Madero 2013-10-28 01:50:36 UTC
I am testing under master not alpha, perhaps it was fixed between alpha and my build of master which was just 2 days ago. You mind testing daily build found here:

http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2013-10-27_23.53.26/
Comment 7 esafe11 2013-10-28 21:48:13 UTC
i tested it ( http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2013-10-27_23.53.26/ ) and the header and footer still revert back to white when i reopen the docx file.
(i'm using windows 7 32-bit)
Comment 8 esafe11 2013-10-28 21:50:00 UTC
*more specifically the microsoft word 2007/2010 docx
Comment 9 Joel Madero 2013-10-28 23:03:51 UTC
I will retest on my Windows 8 machine to see what results I see - on Linux I definitely see the problem in 4.1 but not 4.2.

One more question, you mind resetting your profile with the daily build? https://wiki.documentfoundation.org/UserProfile


Thanks for the help. I'm going to take it a level further and see if you have some time to help test Windows bugs in general - we need some help with triaging Windows bugs, if you have some time - shoot me an email and I'll help you get started :) Thanks!
Comment 10 QA Administrators 2015-04-01 14:40:59 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2015-04-22 14:41:39 UTC
(In reply to esafe11 from comment #5)
> i tested it out on 4.2alpha0+ and the header and footer still reset
> themselves to white. something i noticed (in 4.2alpha0+): in the "borders"
> tab the "left" and "right" "spacing to contents" stay as i have set them
> upon reopening but the "top" and "bottom" change themselves (upon reopening)
> to "0" AND under the "page" tab the "top" and "bottom" margins change
> themselves to the numbers that were in the "top" and "bottom" of "spacing to
> contents".

Reproduced.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64)
Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17
Locale: fi_FI
Comment 12 QA Administrators 2016-09-20 09:33:33 UTC Comment hidden (obsolete, spam)
Comment 13 Justin L 2018-07-25 12:08:20 UTC
Created attachment 143748 [details]
colorPage.odt: 30 pt border, zero page margins

If I remember correctly, .docx format can only have a small spacing by the borders. So LO has to emulate this.

Confirming that the border becomes zero, and all the spacing has been transferred to the page margins.
Comment 14 QA Administrators 2019-07-30 03:17:05 UTC
Dear esafe11,

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!

Warm Regards,
QA Team

MassPing-UntouchedBug