1759984 - If pdf.js is disabled, PDF doesn't appear as a document type in the applications list in Firefox settings

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Dalacor]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

We have a user.prefs policy deployed
user_pref("pdfjs.disabled", true);

This disables Firefox built in pdf viewer thus defaulting to always ask for pdf files. This worked perfectly in previous versions of Firefox prior to 98

Actual results:

Upon upgrading to Firefox 98, pdf's now download automatically to the downloads folder. There is now no setting for pdf's in the application area of Firefox settings, so we cannot change (via gui) what settings we want for Firefox 98.

Expected results:

Firefox should be asking whether we want to download or open the pdf - using the system default pdf viewer which is Tracker Pdf Xchange Editor. Failing that, we should have an option to change the setting back to always ask in the application settings.

In another discussion, I was advised that this should not be happening and the cause may be as result of the user_pref setting to disable pdfs (Firefox Pdf).

This concludes the bug defect section.

Comment 1

[Dalacor]

Firefox 98 has changed the way pdf's are handled.

In the past, the options were to view in Firefox Pdf, open with an external pdf viewer or download. This worked very well for everyone. We have always defaulted to always ask and either saved the file (the location also has always been set to always ask so people download the file to the correct folder location), or we simply open the document which would open our pdf viewer program.

The new way that Firefox has of working has several flaws.

Issue one

Firefox 98 has now moved downloading temp files (pdf's that you open) from the temp folder to the downloads folder. So while it appears that Firefox is now downloading every pdf you open, I realise that this always happened, but out of sight in the temp folder. I understand the logic of making it easier for users to find a file that they viewed, but did not download because they don't know to look in the temp folder.

The problem with this is that users use the downloads folder to save files they are working on (outside browser use) and they use this folder to download documents that they want to view and keep for a short while. So the new Firefox view method is cluttering up the downloads folder with even more files, most of which will never be viewed or opened after the initial viewing.

My recommendation would be to do the following. Have a default Firefox downloads folder and a separate default Firefox View folder - both within the downloads folder. So the downloads folder can be used for saving work that you are temporarily working on - for example I will often save Windows ISO images that I am working on in the downloads folder as I don't want to save it to an area that gets backed up as I don't want to backup ISO images.

Then you have a folder called Firefox Downloads - which will save all files that the Firefox user explicitly downloads. You also have a second folder called Firefox Viewed, which is where Firefox can save all documents that are viewed - so this folder in effect becomes the Firefox temp folder. Even better would be an option to clear out files older than three months in the Firefox Viewed folder just like the temp folder gets cleared out.

This would solve the biggest frustration with the new way of viewing pdf's in an external pdf viewer and makes it easier for users to find a document that they viewed earlier but did not download. So it achieves your aims of helping users find documents that they viewed earlier and solves the problem of removing clutter from the downloads folder which makes it very difficult to find files that the user has explicitly saved. Many pdf's in for example accounting programs don't need to be saved, simply viewed. You need a Firefox Temp folder in the downloads area!

Issue two

As highlighted in the original bug report above, if you disable the Firefox pdf viewer, upon upgrading to Firefox 98, there are no longer any pdf settings in the application area in settings. So users have no ability to revert back to always ask or open with. The pdf's simply download now. So we have lost the ability to view pdf's completely whether in n Pdf Xchange Editor or the internal pdf viewer. We are going to fix this by moving to Firefox ESR version.

Issue three

Several users have raised the issue of security and driveby viruses. If you drop the ability to allow users to choose whether to save or view as a preview, you have effectively enabled driveby's and any dangerous files to download without user knowledge or permission. From a security point of view, this is a terrible idea. I believe that users should by default have the choice to always ask to ensure nothing is downloaded without our explicit knowledge to protect against driveby etc.

Issue four

The default for Firefox 98 is to automatically download files to the downloads folder. With pdf's the default is to view within Firefox browser. I believe that the default should be to ask because many people might want to view documents not save them as very often we don't need to keep the documents, but other times we want to save them. Secondly, for pdf's, we already have a pdf program and for user consistency is very important to use the same pdf viewer everywhere - so it makes sense to default to using the system pdf viewer. Both Firefox and Edge have limitations with their pdf viewer versions which are not present in the external pdf viewer. in addition, the major difficulty with using the Firefox pdf is that they open in new tabs. Tabs are great for a number of things, but when you want to compare different invoices - you want side by side view!

We will be upgrading to Firefox ESR so that we can restore the original functionality as I believe that Firefox 98's approach to saving/viewing pdf's etc is flawed for the above reasons. We now have a potential Security risk of Driveby's. If you have set Firefox Browser to disabled, we now no longer can view any pdf's - they are all downloading. You have conflated the Downloads folder with the temp folder instead of having two folders - one to view and one to download (as suggested above and the fourth issue is many people very often want to view or save pdf's depending on what the document is. Changing the default to download is not good. I believe my suggestion of two separate folders within downloads and allowing users to save/view would be a much better solution.

Thank you.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[:Gijs (away/busy until Mar 10)]

(In reply to Dalacor from comment #1)

Firefox 98 has changed the way pdf's are handled.

In the past, the options were to view in Firefox Pdf,

I'm kind of confused, because in comment 0 you indicated you disabled this? Is it disabled only for some users, perhaps?

My recommendation would be to do the following. Have a default Firefox downloads folder and a separate default Firefox View folder - both within the downloads folder. So the downloads folder can be used for saving work that you are temporarily working on - for example I will often save Windows ISO images that I am working on in the downloads folder as I don't want to save it to an area that gets backed up as I don't want to backup ISO images.

We considered this, but originally decided against it. I'll have folks re-evaluate this suggestion in bug 1738574, as it seems orthogonal to the issue in comment 0.

Issue two

As highlighted in the original bug report above, if you disable the Firefox pdf viewer, upon upgrading to Firefox 98, there are no longer any pdf settings in the application area in settings.

Can you not right click a PDF in the downloads panel and choose "always open similar files"? That should cause an entry for PDFs to appear in the list in the Firefox settings, which you can then adjust to "always ask". If this doesn't work we would really like to know and fix that.

Issue three

Several users have raised the issue of security and driveby viruses. If you drop the ability to allow users to choose whether to save or view as a preview,

The choice is still there; users can configure downloads to always prompt for a location. All other browsers also download files automatically in this way by default. We're still investigating more options in bug 1747343.

Issue four

The default for Firefox 98 is to automatically download files to the downloads folder. With pdf's the default is to view within Firefox browser. I believe that the default should be to ask because many people might want to view documents not save them

As I explained in the other bug, that is precisely why we switched to "always open in Firefox". Users can still save the files they do want saving using the "save" option in the Firefox pdf viewer's toolbar.

Secondly, for pdf's, we already have a pdf program and for user consistency is very important to use the same pdf viewer everywhere - so it makes sense to default to using the system pdf viewer.

Unfortunately, on Windows, Edge takes the system PDF viewer spot by default. So it isn't a given that the system PDF viewer (ie Edge) is more reliable for viewing PDFs than Firefox.

Comment 4

[Dalacor]

1. (In reply to Dalacor from comment #1)

   Firefox 98 has changed the way pdf's are handled.

   In the past, the options were to view in Firefox Pdf,

I'm kind of confused, because in comment 0 you indicated you disabled this? Is it disabled only for some users, perhaps?

Sorry that should mean the three options - and I set it to open with pdf Xchange Editor as the default pdf application to open with.

2. I would highly recommend re-considering some option to separate firefox viewed files versus firefox download files. Using the downloads folder as the new windows temp folder is not going to work very well for many who save files to the downloads folder as they won't be able to find the file they downloaded a week ago.

3. I tried your your suggestion of downloading the file and then clicking on it in the downloads panel to set an option. This restored it back in Firefox application area. So we can fix it, but the question is why it disappeared in the first place.

4. Yes I know that we can set the default to always ask to protect against driveby and I am aware that other browsers do the same. I am just suggesting that the default should be to always ask as this is more secure. I was suggesting making always ask to be the default setting to improve security.

5. We don't use Edge Pdf viewer. Our system default is Pdf Xchange Editor by Tracker Software. The edge viewer is probably on a par with the Firefox viewer, but there are some limitations to using the inbuilt browser pdf viewer. Which is why all our network users are defaulted to using Pdf Xchange Editor. So we are not comparing Firefox pdf and Edge Pdf as we don't use Edge at all.

As long as we can set Firefox to always ask and use an external pdf program (our system default) using central management (currently I do this by deploying a user.js file to each user's Mozilla Profile folder, then I am happy with that. The only major concern I have is the dumping of all temp files into the downloads folder. As the other bug is already covering this, I won't add to it as this has all been covered in other bug posts. I can predict the dumping of temp files into the downloads folder is going to make a lot of users unhappy, so I think a better solution to this should be found. However, I will leave it as it's already been raised elsewhere.

For the moment, we will be moving to Firefox ESR so we can restore the original behaviour of downloading files to the temp folder until this issue has been resolved one way or another. Thank you.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[:Gijs (away/busy until Mar 10)]

We'll use this bug to ensure PDF shows up in the list even if PDF.js is disabled. I believe the other issues you mentioned are covered by other bugs.

Comment 7

[Neil Deakin]

Attachment: Bug 1759984, always show pdf in applications list even when the internal pdf viewer is disabled, r=gijs

In addition, if someone has pdf set to open internally but then disables the pdf viewer, an error occurs when trying to view a pdf. Handle this case by just asking what to do.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39971d9eddfc
always show pdf in applications list even when the internal pdf viewer is disabled, r=Gijs,preferences-reviewers

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/39971d9eddfc

Comment 10

[Dalacor]

Thank you for investigating and fixing this issue in the next release. Much appreciated.

Comment 11

[:Gijs (away/busy until Mar 10)]

Neil, is this safe for uplift to 100 do you think? If so, would you mind requesting beta uplift? Thank you!

Comment 12

[Neil Deakin]

Comment on attachment 9271562 [details]
Bug 1759984, always show pdf in applications list even when the internal pdf viewer is disabled, r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: The reporter is using a preference policy that disables the pdf viewer. If a user has the pdf viewer disabled, pdf does not appear in the applications preferences, so the user cannot change how a pdf should be opened.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Only affects non-default preferences.
• String changes made/needed: None
• Is Android affected?: No

Comment 13

[Dianna Smith [:diannaS]]

This would need to go into release since we are in RC week and no longer in beta for 100. It seems we could wait until beta next week for 101 instead but please let me know if you feel this must go into the 100 release candidate.