Bug 122075 - Print to File writes to incorrect file
Summary: Print to File writes to incorrect file
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Print
  Show dependency treegraph
 
Reported: 2018-12-13 13:33 UTC by Karl Relton
Modified: 2019-02-07 20:08 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot showing chooser file name issue (82.08 KB, image/png)
2018-12-13 13:35 UTC, Karl Relton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Relton 2018-12-13 13:33:22 UTC
Description:
This bug only occurs when using the GTK3 dialogues (libreoffice-gtk3 installed), and when PDF is the print-job language.

Under certain conditions print to file over-writes an existing pdf file in the chosen folder which doesn't match the name chosen by the user (and without any warning or confirmation dialog).


Steps to Reproduce:
Steps to reproduce are:
1) Create an empty directory (folder)
2) Put in directory a dummy pdf (e.g. touch sample.pdf)
3) Open libreoffice and create a writer document with a few words
4) Save the libreoffice document to the directory as a regular writer doc (e.g. 'test.odt')
5) Do 'File -> Print' and choose 'Print to File'
6) In the (gtk3) File-chooser dialog:
  6a) navigate to the folder created in step 2
  6b) select 'Any Type' in the 'types of file shown' selector
  6c) click on the file name 'test.odt'
  6d) in the 'Name' text field, then edit the name from 'test.odt' to 'test_2.pdf'
  6e) then press 'Enter' (or click on 'Select')
7) Observe that in the folder there is no file 'test_2.pdf'. However the dummy file 'sample.pdf' has been over-written and contains the pdf that resulted from the 'print to file' operation


Actual Results:
Observe that in the folder there is no file 'test_2.pdf'. However the dummy file 'sample.pdf' has been over-written and contains the pdf that resulted from the 'print to file' operation

Expected Results:
What should of happened is that the file 'test_2.pdf' should have been created as a pdf of the writer document.


Reproducible: Always


User Profile Reset: No



Additional Info:
The bug appears to be a problem with the 'File Type selector' button. If (having done steps 1 to 6d above) you then manually change the file type selector back to 'Portable Document Format' you will see:
a) it loses your modified name in the Name type-in field
b) it chooses a name in the list of pdf files in the folder, and selects that

That shouldn't happen, because it means the user loses his/her file name they entered.

I suspect that when 'Save' is pressed, the file type selector is being triggered to change automatically to 'Portable Document Format' which is then changing the selected file name ... as a race again the 'Save' operation actually happening.
Comment 1 Karl Relton 2018-12-13 13:35:43 UTC
Created attachment 147499 [details]
Screenshot showing chooser file name issue

This screenshot manages to show the problem.

Here I have typed in the 'Name' field 'test_2.pdf' when I already have that filename in my folder (as well as the dummy sample.pdf). I then press Enter, expecting to get the confirmation dialogue box asking about overwriting the file.

The confirmation box appears, but look at it carefully compared to what the FileChooser GTK3 widget is now showing behind it: the confirmation box shows name 'test_2.pdf' (which is what I typed), and the GTK3 widget not shows 'sample.pdf' (and also has changed the type selector to 'Portable Document Format'. Pressing 'okay' results in 'sample.pdf' being overwritten.

I think the bug happens when the dialogue self-flips the type selector to 'Portable Document Format'.
Comment 2 Xisco Faulí 2019-01-21 14:49:54 UTC
Thank you for reporting the bug.
it seems you're using an old version of LibreOffice.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 3 Karl Relton 2019-01-21 16:18:02 UTC
Tried testing 6.1.4 suing a 'snap' and it appears okay
Comment 4 Xisco Faulí 2019-02-07 20:08:30 UTC
(In reply to Karl Relton from comment #3)
> Tried testing 6.1.4 suing a 'snap' and it appears okay

Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.