Bug 47572 - PRINTING: Print Options Saved in Spite of Cancelling Print Dialog
Summary: PRINTING: Print Options Saved in Spite of Cancelling Print Dialog
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 80872 (view as bug list)
Depends on:
Blocks: Print-Dialog
  Show dependency tree / graph
 
Reported: 2012-03-20 05:23 UTC by Harald Koester
Modified: 2023-06-28 03:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2012-03-20 05:23:53 UTC 
Problem description: 

Steps to reproduce:
[1] Start LibreOffice and open a new text document.
[2] File > Print... > tab "LibreOffice Writer"
[3] Change one the displayed options. Then "Cancel".
[4] File > Print... > tab "LibreOffice Writer". The changed option has been saved, despite of cancelling the dialog.

As far as I checked this problem, all options of the tab 'LibreOffice Writer' and the option "Brochure" of tab 'Page Layout' are saved if cancelling the dialog. Possibly also the option "Print Comments" of tab 'General', but I did not checked it.

Expected behaviour: 
If the Print Dialog is cancelled, changed options should not be changed.
Or better: Message: "You have changed print options. Do you want to save them?"

Hint: bug 33245, bug 42657 and bug 43932 also deal with print options.

Problem also observed with V. 3.4.5.
              
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28
Comment 1 sasha.libreoffice 2012-06-13 23:42:48 UTC 
Thanks for bugreport
reproduced in 3.5.4 on Fedora 64 bit (Windows not tested)
When click "Cancel" then options saved, but when close LO and open again, options resets to defaults.

May be here should be added button "Apply" for saving options. And "Cancel" should not save options.

IMHO users print most documents with the same options. Only some document needed to be printed with different options. And then arises another problem: how to not forget to change options to previous state again.
So, adding ability to set default printing options may be very useful.
Comment 2 Harald Koester 2012-06-25 05:12:45 UTC 
Not only when closing LO, also when opening a new document, print options for this document are determined by the options determined in the dialog Tools -> Options -> LibreOffice Writer -> Print. This means most documents are printed with the same options. That's OK for me.

But if you go on with the steps to reproduce:
[5] Cancel dialog and insert some words. 
[6] Close and save the document.
[7] Close LO and start it again.
[8] Open document again.
[9] File > Print... tab "LibreOffice Writer". You see the changed option (despite Cancel) has been saved together with the document.
And this is not OK for me.

I am not convinced, if an additional button ("Apply" or "Save Print Options" or similar) makes sense, because may be some users (especially less experienced users) may be irritated by such a button. To my opinion print options should be saved together with the document, if it or a part of it has been printed. 

A little problem rises here: Shall the "Document's Change Status" change to "Changed", even only print options have been changed and the document itself has not been changed? In case of "Changed" of the stauts the user would be prompted to save the document at the end of his LO session, even he did not change the document itself.
Comment 3 Joel Madero 2012-09-09 03:45:46 UTC 
Confirmed, setting as NEW, prioritizing and assigning to myself

Priority - MINOR - MEDIUM

I marked as Minor, Medium because, while it's not affecting ability to really make high quality work, it doesn't reflect well on LibreOffice to have cancel and Ok mean the same thing for our options. Also, I think the potential to irritate enough users is high enough to quality for a medium priority
Comment 4 Joel Madero 2013-02-01 19:19:00 UTC 
Hey Michael, 

I was hoping you could mentor me a bit on this one. I think I have the relevant code: 

http://opengrok.libreoffice.org/xref/core/sw/source/ui/uno/unotxdoc.cxx#2439

and I believe it needs to be moved out of sw and into the general printdlg.cxx in order to capture the push of "Ok Button" 

http://opengrok.libreoffice.org/xref/core/vcl/source/window/printdlg.cxx

This way I think also it would be much easier to implement saving preferences from other components as well. 

Looking to:
a) confirm I'm on the right track
b) Get pointers on how I move the stuff from unotxdoc.cxx to printdlg.cxx as they are in completely different areas of core (vcl vs. sw), so there are a bunch of hxx files associated. Do I move them all one by one, do I make new hxx files, link them somehow without moving anything?

Many thanks and apologies for the ping
Comment 5 Joel Madero 2013-03-23 20:33:17 UTC 
if someone wants to take this away from me, feel free to do so - I think someone with a bit more skill could get it done relatively fast. Here is an email that I got from Caolan
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
short answer is that what we want to happen is roughly
a) remove that implicit store of settings in the writer code where it
happens as a side effect and get it called explicitly in some store
options configuration e.g.
in PrintDialog::storeToSettings have a maPController->storeUIOptions();
call and that maPController fundamentally comes from 
new SfxPrinterController in sfx2/source/view/viewprn.cxx and takes a
SfxViewShell as an argument so it should be possible somewhere around
there to add a virtual storeUIOptions to the vcl::PrinterController,
implement it in SfxPrinterController and propagate (here its the usual
frustrating haze of "shells") the task to yet-another app-specific
virtual store method and move the writer implicit-save code into that
method instead. 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comment 6 QA Administrators 2013-07-18 19:20:31 UTC 
Unfortunately I just haven't had the time to solve this bug - if I make any progress I will report back but until then setting back to default and NEW
Comment 7 tmacalp 2014-07-08 21:17:50 UTC 
*** Bug 80872 has been marked as a duplicate of this bug. ***
Comment 8 Joel Madero 2014-11-06 03:28:36 UTC 
I have no time to continue looking into this - setting assigned to default.
Comment 9 OfficeUser 2015-06-24 19:53:27 UTC 
LibreOffice 4.4.2.2. release is still affected. I just wanted to file an issue but I have found this one.

I found out that the "Print" "Comments" settings in the tab "General" are saved by clicking on Cancel.
Comment 10 QA Administrators 2016-09-20 10:11:18 UTC Comment hidden (obsolete)
Comment 11 Harald Koester 2016-10-01 12:13:20 UTC 
Bug still exists in version 5.2.2 with Win7.
Bug already exists in version 3.3.0. Hence inherited from OOo.
Comment 12 QA Administrators 2017-10-23 14:15:08 UTC Comment hidden (obsolete)
Comment 13 tmacalp 2017-11-03 13:19:28 UTC 
Can still repro in
Version: 5.4.2.2
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 14 QA Administrators 2019-06-21 02:52:28 UTC Comment hidden (obsolete)
Comment 15 Harald Koester 2019-06-27 13:16:58 UTC 
Bug still exists in version 6.2.4 (64 bit) with Win10.
Comment 16 QA Administrators 2021-06-27 04:19:45 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2023-06-28 03:13:11 UTC 
Dear Harald Koester,

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