Bug 267350 - filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
Summary: filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/doc...
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 0.19.60
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
: 343852 357741 372488 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-01 01:04 UTC by Wren Turkal
Modified: 2018-11-28 10:03 UTC (History)
26 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
IRS form W9 (103.61 KB, application/pdf)
2011-03-01 01:04 UTC, Wren Turkal
Details
Filled in file (105.12 KB, application/octet-string)
2013-04-03 20:11 UTC, Albert Astals Cid
Details
Filled file with poppler 0.22 (105.13 KB, application/pdf)
2013-04-04 18:05 UTC, Albert Astals Cid
Details
pdf with notes and drawing (117.48 KB, application/octet-string)
2013-04-05 00:41 UTC, Mark
Details
File for which forms only appear in Okular, not Adobe Reader (65.43 KB, application/pdf)
2013-06-19 15:18 UTC, Rajiv Gupta
Details
Same form filled out in Adobe (70.86 KB, application/pdf)
2013-06-19 18:26 UTC, Rajiv Gupta
Details
XFA-warning (21.94 KB, image/png)
2013-06-20 11:35 UTC, Fabio D'Urso
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wren Turkal 2011-03-01 01:04:35 UTC
Created attachment 57582 [details]
IRS form W9

Version:           0.11.1 (using KDE 4.5.3) 
OS:                Linux

I just realized that Okular is storing my form data in a file that is not the PDF itself. This file is hard to find and means that my social security number is stored in some random file on my machine if I fill out an IRS form W9 with Okular. This seems less than ideal from a UX perspective.

I could not find a way to delete the data short of deleting the files from the command line. Not storing the data with the PDF is really user hostile in my opinion.

Also, when I "Save As..." a PDF with filled out forms, only the first field appears to be saved in the new PDF. For the record, Evince appears to have this same bug. This may be an indication of a bug in the poppler library.

Reproducible: Always

Steps to Reproduce:
1. Open fw9.pdf IRS form.
2. View forms
3. Type in data
4. Close Okular.
5. look in ~/.kde/share/apps/okular/docdata/

Actual Results:  
There are files containing potentially private data in that directory, and it's hard for a casual user to delete them.

Expected Results:  
The user should be able to "Save as..." to a new file and just have a copy of the PDF with the filled in form data.

OS: Linux (x86_64) release 2.6.37-1-amd64
Compiler: cc
Comment 1 Jackson Peacock 2011-04-04 03:11:36 UTC
I just noticed the same issue. I had stored some filled out forms on an encrypted drive. I ran into a bug where the fields I entered didn't weren't being displayed after being saved (not even an empty field). I figured the file had been corrupted so I copied the original blank form over the filled out one. When I opened it all the information I had entered into the form was there despite the file having been overwritten. After looking around I found it had been written to .kde/share/apps/okular/docdata - on an unencrypted drive. This was quite startling to me and not what I expected. 

I can understand if there are limitations to the PDF format that prevent you from storing the data in the PDF file itself, however you should at least inform the user of where the data is being stored before writing it. Preferably, it should be stored in the same directory as the PDF as well.
Comment 2 Jackson Peacock 2011-04-10 20:04:21 UTC
Another limitation of doing it this way is that it appears impossible to have multiple copies of the same form filled out differently, even if saved in different directories. For example, I filled out my tax forms, and then created a new directory with the copied blank forms to do my girlfriend's taxes. However, when I opened them they had my value stored in them. 

The workaround was to rename the forms and then edit them, but it would match user expectations better if each copy of the form had it's own set of values.

Finally, I do think the priority on this bug should be higher as it relates to user privacy/security.
Comment 3 jordonwii 2012-01-05 05:26:15 UTC
Agree with #2. I know the devs are aware of this because there are other issues regarding the opening files and having the form remain being filled out (intentional feature). However, unsure if they are aware of the security implications of this. Developers have any comment?
Comment 4 jamesp 2012-07-25 21:06:45 UTC
I ran into this problem too recently. In one department at my workplace, I set up a computer where employees can read PDFs and fill out PDF forms. There is one particular form that each of them has to fill out every two weeks. I discovered that I could avoid the problem of each person seeing (and having to delete) the details entered by the previous person by renaming the pdf file to a random temporary filename before opening it. Then I realized that by serving the pdf file from a local webserver, and having them open the pdf from a link in firefox, I would get the random temporary filename for free without having to script it. It is certainly a kludge, but it seems pretty usable for now :)
Comment 5 Uwe Geuder 2012-10-12 21:18:31 UTC
Besides form data also annotations were served in that extra docdata xml file.

For annotations this has been fixed recently: https://bugs.kde.org/show_bug.cgi?id=151614

I haven't had time yet to read the whole lengthy discussion there or to install the new version to see whether /how it affects form data.
Comment 6 Marcus Furlong 2013-04-03 01:26:52 UTC
Have just been bitten by this as well. The form I returned did not contain any form data.

A user should reasonably expect that form data is saved with the form, as this is what other pdf viewers do, and this is what the "File->Save As" option suggests it does. For a long form that has that has taken the user days to fill in, this is definitely an unexpected and unwelcome bug.

popper 0.22.1
okular 0.16.0 on kde 4.10
Comment 7 Marcus Furlong 2013-04-03 01:59:27 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Albert Astals Cid 2013-04-03 17:34:01 UTC
Marcus your problem has nothing to do with this bug, Warren is complaining about the data leakage into his own home folder.

What you are facing has nothing to do with this. So please open a separate bug about it.
Comment 9 Wren Turkal 2013-04-03 19:05:54 UTC
To quote my original description:

Expected Results:
The user should be able to "Save as..." to a new file and just have a copy of the PDF with the filled in form data.

I believe this is exactly what Marcus was asking for.
Comment 10 Albert Astals Cid 2013-04-03 20:11:11 UTC
Then you used a wrong subject and i decided to ignore this bug, "Save as..." should and does work here, please, i'm attaching a filled in (just the first two lines) with okular of the file you attached that opens fine in Adobe Reader and shows the data
Comment 11 Albert Astals Cid 2013-04-03 20:11:53 UTC
Created attachment 78620 [details]
Filled in file

With "Hola" and "Pepe" in the first two lines
Comment 12 Albert Astals Cid 2013-04-03 20:15:32 UTC
FWIW that filled in file was created with poppler 0.23 and can't be opened with 0.22 or older :-/ But that's a bug of those old versions, you can open it with Adobe Reader to see it working
Comment 13 Marcus Furlong 2013-04-03 23:31:47 UTC
It's the same bug, just a different title. Instead of saving the form data to the PDF, it gets saved externally.

Happy to hear it's solved in a newer version of poppler. 0.23 is the development branch of what will become 0.24?
Comment 14 Albert Astals Cid 2013-04-04 18:05:04 UTC
Oh no, 0.22 works too, i just created it with 0.23 because it was what i had installed, let me attach one created with 0.22
Comment 15 Albert Astals Cid 2013-04-04 18:05:36 UTC
Created attachment 78638 [details]
Filled file with poppler 0.22
Comment 16 Marcus Furlong 2013-04-04 23:57:47 UTC
The must be something different in our environments then. I'm using opensuse 12.3, okular 0.16.0 on KDE 4.10.0. Is there a compile-time option to enable this in poppler or okular?

I downloaded your second attachment and I can see the form data you have entered. I add my own form data and save, and when I close okular and reopen the same file, the text is there. But my text is saved externally. If I do the following, the form data reverts to your text

> mv morsa.pdf morsa1.pdf
> okular morsa1.pdf

and the form data I had saved is only visible in .kde4/share/apps/okular/docdata/107650.morsa.pdf.xml
Comment 17 Mark 2013-04-05 00:19:37 UTC
Hello, Archlinux, kde 4.10.2, okular 0.16.2, I confirm I can open morsa.pdf and see the filled in fields(!), file elefante.pdf fails to even open. 

@Marcus: 
I confirm mv file and open keeps the filled in data. (Note difference between Save as.., and Save a copy)

Backends here: 

$ pacman -Qs poppler
local/poppler 0.22.2-1
    PDF rendering library based on xpdf 3.0
$ pacman -Qs ghostscript
local/ghostscript 9.07-1
    An interpreter for the PostScript language

ghostscript is mentioned in Okular as backend. 

It would be perfect if forms started to work! :)
Comment 18 Mark 2013-04-05 00:41:26 UTC
Created attachment 78649 [details]
pdf with notes and drawing

Btw, if it helps, taking notes (drawing, stamps, highlighting etc) saves properly. Please verify painting2.pdf
Maybe the forms could be done in same way.
Comment 19 Albert Astals Cid 2013-04-05 18:21:31 UTC
Marcus i can't help you here, i've proven it works as it has worked for a long time to be honest i should close this bug since it's basically a weird worded bug and people is just commenting on it with unrelated comments, if it doesn't work for you, you're doing something wrong or opensuse compiled something wrong, but not sure how can i help you debug it.
Comment 20 Rajiv Gupta 2013-06-19 02:58:57 UTC
It seems that when I fill out a form with Okular (with poppler 0.22), it opens in Okular when I rename it or move it to another computer. But no matter what, it doesn't open in Adobe Reader.
Comment 21 Yuri Chornoivan 2013-06-19 04:36:25 UTC
(In reply to comment #20)
> It seems that when I fill out a form with Okular (with poppler 0.22), it
> opens in Okular when I rename it or move it to another computer. But no
> matter what, it doesn't open in Adobe Reader.

Please use "File -> Save as..." to save filled data with your PDF file.
Comment 22 Rajiv Gupta 2013-06-19 15:17:32 UTC
I used save as, but I think it only happens with some PDF files. The tax form works perfectly, but I am attaching a file for which the filled out forms only appear in Okular, but not Adobe Reader.
Comment 23 Rajiv Gupta 2013-06-19 15:18:56 UTC
Created attachment 80639 [details]
File for which forms only appear in Okular, not Adobe Reader
Comment 24 Yuri Chornoivan 2013-06-19 16:23:04 UTC
FoxIt Reader (under wine) shows filled forms.

It can be a bug in Adobe Reader (tested version XI (11.0.03), also under wine).
Comment 25 Rajiv Gupta 2013-06-19 18:23:46 UTC
I am attaching the same form filled with Adobe.
Comment 26 Rajiv Gupta 2013-06-19 18:26:03 UTC
Created attachment 80647 [details]
Same form filled out in Adobe

This form opens in both Okular and Adobe.
Comment 27 Fabio D'Urso 2013-06-20 11:35:38 UTC
Created attachment 80666 [details]
XFA-warning

(In reply to comment #23)
> Created attachment 80639 [details]
> File for which forms only appear in Okular, not Adobe Reader
Yes, it's known issue. Basically that file uses a newer format to store form data, which is currently unsupported by poppler (and probably won't be for a long time, because it's very complex).
However, Okular from 4.10 with poppler 0.22 should warn you (see attached screen), doesn't it?
Comment 28 Rajiv Gupta 2013-06-20 16:46:58 UTC
No I don't get that warning (using KDE 4.10.3), but I found a workaround, which is to print the file to a PDF, which opens with Adobe. And now I'm going to do a "sudo apt-get purge acroread acroread-bin". (When I installed it 2 days ago, it created a file located in / called C:\nppdf32Log\debuglog.txt)
Comment 29 Aaron Wolf 2013-10-21 20:34:41 UTC
This is obnoxious. My partner sent me a file with forms filled. I changed them. There's NO WAY to keep having editable forms and send her back the file with the changes!

I tried "save as" and still get the old data there. I had to do it as a print, which means she then manually updates in her program.

This situation is horrible.
Comment 30 Yuri Chornoivan 2013-10-22 04:48:07 UTC
(In reply to comment #29)
> This is obnoxious. My partner sent me a file with forms filled. I changed
> them. There's NO WAY to keep having editable forms and send her back the
> file with the changes!
> 
> I tried "save as" and still get the old data there. I had to do it as a
> print, which means she then manually updates in her program.
> 
> This situation is horrible.

This is not the way to report bugs. Please give developers some information about your system (name and version), version of Okular and version of Poppler libraries (can be determined with "pdftops -v" command in console or using your favorite package manager).

BTW, just works here (even for XFA documents if Foxit reader used).
Comment 31 Aaron Wolf 2013-10-22 05:39:42 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > This is obnoxious. My partner sent me a file with forms filled. I changed
> > them. There's NO WAY to keep having editable forms and send her back the
> > file with the changes!
> > 
> > I tried "save as" and still get the old data there. I had to do it as a
> > print, which means she then manually updates in her program.
> > 
> > This situation is horrible.
> 
> This is not the way to report bugs. Please give developers some information
> about your system (name and version), version of Okular and version of
> Poppler libraries (can be determined with "pdftops -v" command in console or
> using your favorite package manager).
> 
> BTW, just works here (even for XFA documents if Foxit reader used).

Sorry, I just assumed this was the same as the original bug, i.e. an intentional and flawed design. I didn't think this was behaving differently from intended, I thought the issue was simply that the intention was a bad one.

If you intend it to actually work reasonably (which I'd hope), and it is something about my system, well: I'm on KXStudio, which is a derivative of Ubuntu. I'm using standard KDE 4.11.2 and Okular 0.17.2 and pdftops 0.18.4.

To clarify: if I open and change the forms myself, they persist on my machine. If I send the form as an e-mail to someone else, they lose my form changes. If I "save as" on my own machine, the new file reverts to the old form data and loses my changes even on my machine. Note that this is a case where the file I got from someone else started with some form data already, entered in some program other than Okular, and I was changing it.
Comment 32 Yuri Chornoivan 2013-10-22 07:55:36 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > This is obnoxious. My partner sent me a file with forms filled. I changed
> > > them. There's NO WAY to keep having editable forms and send her back the
> > > file with the changes!
> > > 
> > > I tried "save as" and still get the old data there. I had to do it as a
> > > print, which means she then manually updates in her program.
> > > 
> > > This situation is horrible.
> > 
> > This is not the way to report bugs. Please give developers some information
> > about your system (name and version), version of Okular and version of
> > Poppler libraries (can be determined with "pdftops -v" command in console or
> > using your favorite package manager).
> > 
> > BTW, just works here (even for XFA documents if Foxit reader used).
> 
> Sorry, I just assumed this was the same as the original bug, i.e. an
> intentional and flawed design. I didn't think this was behaving differently
> from intended, I thought the issue was simply that the intention was a bad
> one.
> 
> If you intend it to actually work reasonably (which I'd hope), and it is
> something about my system, well: I'm on KXStudio, which is a derivative of
> Ubuntu. I'm using standard KDE 4.11.2 and Okular 0.17.2 and pdftops 0.18.4.
> 
> To clarify: if I open and change the forms myself, they persist on my
> machine. If I send the form as an e-mail to someone else, they lose my form
> changes. If I "save as" on my own machine, the new file reverts to the old
> form data and loses my changes even on my machine. Note that this is a case
> where the file I got from someone else started with some form data already,
> entered in some program other than Okular, and I was changing it.

It seems that poppler libraries in your system are too old (Okular itself is up-to-date). You need to install at least poppler-0.20 (or better 0.22) to have reliable forms and annotation editor which can save the data in PDF. Try to find some PPA with newer version (Debian Sid has 0.18.4, Ubuntu 13.04 has 0.20.5 and Ubuntu 13.10 has 0.24.1). Sorry.

Please take into account that some other applications (e.g. Inkscape) can be dependent on the old version of poppler, so the safest way is to build and install libraries on your own (it is not hard at all, so they do not break anything).
Comment 33 Aaron Wolf 2013-10-22 15:39:11 UTC
> It seems that poppler libraries in your system are too old (Okular itself is
> up-to-date). You need to install at least poppler-0.20 (or better 0.22) to
> have reliable forms and annotation editor which can save the data in PDF.
> Try to find some PPA with newer version (Debian Sid has 0.18.4, Ubuntu 13.04
> has 0.20.5 and Ubuntu 13.10 has 0.24.1). Sorry.
> 
> Please take into account that some other applications (e.g. Inkscape) can be
> dependent on the old version of poppler, so the safest way is to build and
> install libraries on your own (it is not hard at all, so they do not break
> anything).

Oh how strange, thank you. I will figure this out! Sorry to have made assumptions about things…
Comment 34 sparhawk 2014-06-04 00:35:55 UTC
I've used "save a copy" accidentally, not realising that this was fundamentally different to "save as". In a lot of programs these both create a new file, but the former leaves you editing the original, while the latter allows to keep editing the newly created file.

Anyway, I've now realised that there is potentially a lot of private data (e.g. credit card information) stored in plain text on my computer. It seems that some of the information in ~/.kde/share/apps/okular/docdata/ is about the last-used zoom/position of documents? How can I find which of these documents contains form data?
Comment 35 Yuri 2015-04-03 00:11:48 UTC
*** Bug 343852 has been marked as a duplicate of this bug. ***
Comment 36 Yuri 2015-04-03 00:17:38 UTC
Real problem is that okular violates pdf specification: section "8.6.6 Forms Data Format" of PDF reference: http://partners.adobe.com/public/developer/en/pdf/PDFReference16.pdf

The standard way to store forms is to write the form data into the special section in the same pdf file.

Current way is prone to data loss and confusion, because users will send out the pdf assuming that form is there, when it isn't. Currently form data is implicitly attached to the current pdf file name, which is counter-intuitive.
Comment 37 Yuri 2015-04-03 00:20:47 UTC
I would put the high priority on this, because the major user visible function malfunctions due to misimplementation.
Comment 38 Albert Astals Cid 2016-01-11 22:39:50 UTC
*** Bug 357741 has been marked as a duplicate of this bug. ***
Comment 39 Carsten Gräser 2016-03-10 11:15:59 UTC
I also stumbled about the fact that it seems to be impossible to have multiple instances of the same filled in form under the same file name and got the impression that "Save as..." does not work. After some experimenting I found out the problem with "Save as...":

There's two places where form data is stored: .kde/* and the pdf-file itself. Data is always saved to .kde/* (attached to filename?). If you use "Save as" it's also stored to the file. The problem is that this is not visible to the user and that .kde/* seems to have precedence. If you want to fill the same form twice you can easily run into problems:

Case a: Since form data is visible after closing, reopening, or moving the file, the user assumes that it's stored inside of the pdf. To fill a form a second time he copies the filled in form into a new location and changes the necessary data. Everything seems to work, but if he reopens the original file all it's data is changed to what he entered in the new place.

Case b: The user is aware that data is stored in the file only if he used "Save as". After filling the form the first time he uses "Save as". To fill the form a second time he copies the filled in form into a new location and changes the necessary data and uses "Save as" again. Now different data is saved in both versions of the file. But if he opens version 1 again, he sees the changes he did in version 2. The reason for this is that by changing version 2, the data in .kde/* is changed and this seems to have precedence when viewing version 1. If you delete th corresponding file in .kde/* you see what's stored in the file.

In both cases the user seems to have lost data. In a) this is true, in b) his data is just not visible.
Comment 40 Carsten Gräser 2016-06-08 09:52:16 UTC
Since I stumbled about this again: The following minor changes would increase usability of forms a lot since they make the behaviour of Okular more transparent.

a) Add a menu entry "save form data" that makes Okular store the data in the file itself.
b) When the user tries to close a filled in form without explicitly saving it: Warn the user that the form data is not stores in the file (but only cached somewhere else) and ask if she/he want's to save now.
c) Always give precedence to data saved in the file itself.
Comment 41 Yuri 2016-06-08 17:44:02 UTC
(In reply to Carsten Gräser from comment #40)
> Since I stumbled about this again: The following minor changes would
> increase usability of forms a lot since they make the behaviour of Okular
> more transparent.
> 
> a) Add a menu entry "save form data" that makes Okular store the data in the
> file itself.
> b) When the user tries to close a filled in form without explicitly saving
> it: Warn the user that the form data is not stores in the file (but only
> cached somewhere else) and ask if she/he want's to save now.
> c) Always give precedence to data saved in the file itself.

Carsten, the problem is that there is no code that saves to a file. There should be two choices:
* Saving to a pdf file itself
* Saving to a separate pdf file (according to the pdf spec)
But somebody for some unknown reason implemented writing it in the proprietary format into ~/.kde/share/apps/okular/docdata/ that makes okular unusable for filling forms. Nobody needs the function to save forms under ~/.kde
Comment 42 Carsten Gräser 2016-06-08 20:24:21 UTC
Yuri, this is not correct. Okular can in principle save the data to the pdf. But the interplay of this with saving to and loading from .kde/... is not very intuitive.
Comment 43 Yuri 2016-06-08 20:39:32 UTC
(In reply to Carsten Gräser from comment #42)
> Yuri, this is not correct. Okular can in principle save the data to the pdf.
> But the interplay of this with saving to and loading from .kde/... is not
> very intuitive.

What does it mean "can in principle"? Is the code saving it to the pdf there or not there? If it is there, can you send the link (line numbers)?
Comment 44 Carsten Gräser 2016-06-08 22:17:59 UTC
(In reply to Yuri from comment #43)
> (In reply to Carsten Gräser from comment #42)
> > Yuri, this is not correct. Okular can in principle save the data to the pdf.
> > But the interplay of this with saving to and loading from .kde/... is not
> > very intuitive.
> 
> What does it mean "can in principle"? Is the code saving it to the pdf there
> or not there? If it is there, can you send the link (line numbers)?
I gave a very detailed explanation of "in principle". just try out as described above.
Comment 45 Yuri 2016-06-08 22:47:22 UTC
(In reply to Carsten Gräser from comment #44)
> I gave a very detailed explanation of "in principle". just try out as
> described above.

I don't know what are you talking about. You don't make yourself clear.
Comment 46 Aaron Wolf 2016-06-08 22:57:09 UTC
@Yuri, Carsten was saying that the current Okular behavior *does* save data directly to the PDF *if* you use "save as" but otherwise not. The problem remaining is that it also saves to a hidden directory as well, and then conflicts and security issues can arise from that.
Comment 47 Yuri 2016-06-08 23:17:57 UTC
Ah, I see. I didn't realize the pdf form-saving code was even there. This makes the situation much better than I thought.

Thanks for clarifying this!

Somebody should just remove the code writing under ~/.kde4/share/apps/okular/
Comment 48 Niels Elgaard 2016-10-05 14:07:00 UTC
Today I received a PDF with forms filled in, that I had to forward as a normal PDF (using "save as" or print to PDF file). Some fields worked as expected. But some were missing in the resulting PDF.

After quite some time I tried editing every single form field, ending up with the same values as before, and then printing to to PDF. Then everything working, i.e. all form fields were saved to the PDF file.

I use Okular 0.25,  Platform 4.14.23
Comment 49 Albert Astals Cid 2016-11-14 23:17:09 UTC
*** Bug 372488 has been marked as a duplicate of this bug. ***
Comment 50 lutz.wrage 2017-04-10 15:18:36 UTC
Is there any use case that justifies storing form data in ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in the pdf itself? 
It seems to me that there isn't.
Comment 51 Ross Boylan 2017-10-15 19:26:33 UTC
(In reply to lutz.wrage from comment #50)
> Is there any use case that justifies storing form data in
> ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in
> the pdf itself? 
> It seems to me that there isn't.

While I consider the current behavior undesirable, it does have its advantages.  In fact, it's the reason I decided to use okular for my taxes.  Here's the use case:

1. Generate some forms automatically (e.g., opentaxsolver computes my taxes and fills in government  forms).
2. Resulting forms require some manual tweaks (e.g., check boxes, fill in additional fields).
3. Discover forms need to be regenerated to correct a mistake.  Modify inputs and return to 1.

In this scenario, the work in 2 is lost if the results have been stored in the pdf, but is retained if the values are stored elsewhere, as okular currently does.  Even if the pdf in 2 is saved under a different name, so that the results are not literally lost, one must manually identify the changed information and reenter it.

There is another scenario in which the recreation of the information is less desirable.  If some of the manually entered information in 2 depends on the values from 1, e.g., you manually enter line 55 as a copy of line 32 but the automatically generated line 32 changes, then the previous manual data may be invalid.
Comment 52 Ross Boylan 2017-10-15 21:47:17 UTC
I don't want my previous response to be taken as a vote for the status quo.  The behavior I would expect is:

1. If I don't hit save my work disappears.(*)  The current application does not have a save function (as distinct from save as), and I'm pretty sure that if I fill in a form, exit, and then open the form my old values will still be there.  Worse, if someone else using the same account opens the form, they will see my info.

2. If I do save (not just save as) my work will be saved with the file.

In this case I might not expect, but would be pleased if 
3. there were an option to save the form data to a separate file and restore it from a separate file.  I'd guess such a facility is consistent with the 1600 page XFA spec, though I can't say I know where :)

Because the current behavior violates these expectations, it is a security risk.   Someone's personal information may be exposed in ways unanticipated, and operations that usually assure security, like not saving a file or deleting it, will not work.  And operations that are expected to reveal info, like copying/mailing a pdf or operating on it with a different program, may instead conceal/disappear the information.

(*) Some usability experts argue that "work disappears if I don't save" is not the expectation of the lay user, and that our current model of "you must save to keep your work" is aggravating and unintuitive to them.  That may well be correct.  But unless the surrounding programs all start behaving this way, this behavior is undesirable.  An application that may be dealing with sensitive private information is not the place to pioneer new interface models.
Comment 53 Yuri 2017-10-15 22:01:52 UTC
(In reply to Ross Boylan from comment #52)
> I don't want my previous response to be taken as a vote for the status quo. 
> The behavior I would expect is:

Saving form data into the file is the behavior prescribed by pdf specification.
Leaving form files in any other place has so many disadvantages that it doesn't even make sense to list them.


It's amazing this isn't fixed for 6.5 years now.
Comment 54 Albert Astals Cid 2017-10-15 22:16:25 UTC
Please, stop complaining, complaining doesn't do anyone any good, we know it needs improvement and we're working in a fix.

If you want to get it fixed earlier, either volunteer to help with the fix or hire someone to fix it faster.
Comment 55 sparhawk 2017-10-15 23:07:56 UTC
> we know it needs improvement and we're working in a fix.

To be fair to the other commenters, we hadn't heard anything here for a few years, so I presumed that the devs were *not* working on a fix. Sometimes KDE bugs tend to drift around for a few years before being abruptly closed as "won't fix", so I can understand why people continue to complain.

Also, I was also unaware that you were even a dev until I mouse-overed your name and saw the @kde.org email address just then. I guess that's a fault of this website though; a visible dev tag similar to GitHub would be useful.
Comment 56 Nate Graham 2017-10-15 23:26:10 UTC
Definitely a good idea. Technically I'm a KDE developer too even though I don't have or use a @kde.org email address. Can you file a bug to that effect on https://bugs.kde.org/enter_bug.cgi?product=bugs.kde.org?
Comment 57 Luigi Toscano 2017-10-15 23:30:57 UTC
I'm not sure that highlighting the fact that someone is a KDE devleoper here is a good idea.
If I comment in a bug of a component which I never touched, I'm not sure why that comment should have some sort of special marking.

That said, we are off-topic here; the place to discuss this is the kde-community@ mailing list.
Comment 58 Albert Astals Cid 2017-11-03 16:08:23 UTC
For people that have an idea how to compile and test stuff, please test https://phabricator.kde.org/D8642
Comment 59 Albert Astals Cid 2017-11-16 14:07:55 UTC
This won't be anymore the case starting with the Okular that will be part of KDE Applications 17.12 (aka okular 1.3.0)
Comment 60 Wren Turkal 2017-11-16 16:41:52 UTC
Hi,

OP here. I wanted to reach out and thank you for fixing this issue much more comprehensively than I imagined when I originally filled the issue.


Thanks,
wt