1903610 - [Linux] When opening PDFs in Firefox based on it being the OS default handler and internal PDF viewer is disabled with `pdfjs.disabled`, Firefox creates .part files until I close Firefox

Status: UNCONFIRMED

(Firefox :: File Handling, defect, P3)

Description

[unwell]

Attachment: video.mp4

Steps to reproduce:

I use Fedora, and Firefox was installed through Fedora.
In Firefox settings under Applications, set PDF to "Use Firefox (default)".
Then, open a PDF in Firefox.

I have set Firefox as the default application for opening PDFs.

Actual results:

Firefox generates .part files repeatedly until Firefox is closed.

Expected results:

It should have opened the PDF.

Comment 1

[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 2

[Calixte Denizet (:calixte)]

I've absolutely no idea about what's wrong here, I'm not sure it's a pdf.js bug.
:Gijs, would you have any ideas ?

Comment 3

[unwell]

The glitch occurs when you set 'pdfjs.disabled' to 'true' in about:config, then set Firefox to open PDFs in settings, and finally try to open a PDF.

Comment 4

[:Gijs (he/him)]

(In reply to unwell from comment #3)

The glitch occurs when you set 'pdfjs.disabled' to 'true' in about:config, then set Firefox to open PDFs in settings, and finally try to open a PDF.

... why would you do that?

That is, why would you both tell Firefox "don't open PDFs" and also tell it "hi please open PDFs"?

Comment 5

[unwell]

(In reply to :Gijs (he/him) from comment #4)

(In reply to unwell from comment #3)

The glitch occurs when you set 'pdfjs.disabled' to 'true' in about:config, then set Firefox to open PDFs in settings, and finally try to open a PDF.

... why would you do that?

That is, why would you both tell Firefox "don't open PDFs" and also tell it "hi please open PDFs"?

It wasn't on purpose, I forgot. I had disabled it in about:config.

Comment 6

[:Gijs (he/him)]

I can't reproduce on macOS. I get the "what do you want to do with this file" prompt, because we detect the "infinite loop" situation where you've set Firefox as the OS default for some filetype, and then Firefox decides it can't handle the file when the OS passes it the file. Only one part file is created, which is removed when you close the dialog.

I don't have a Linux machine to hand at the moment to test with, but it's known that on Linux, for some reason, this detection does not work well - probably because "is Firefox the default app" is a harder question to answer as Linux does not have a single unified way of determining which is the default app for a filetype / protocol. See also e.g. bug 1304650 . And then of course there's the snap/flatpak sandboxing...

Comment 8

[Matthias Urlichs]

This also happens when you tell Firefox to use an external program for viewing PDFs, then delete the program in question.

Comment 9

[Matthias Urlichs]

NB detecting the infinite loop shouldn't involve asking the OS whether Firefox is the default handler for the file. It merely requires checking whether a download of the file in question is already in progress (or has just been completed, with the file still available on-disk).

Comment 10

[:Gijs (he/him)]

(In reply to Matthias Urlichs from comment #9)

NB detecting the infinite loop shouldn't involve asking the OS whether Firefox is the default handler for the file. It merely requires checking whether a download of the file in question is already in progress (or has just been completed, with the file still available on-disk).

I don't think I follow this proposal. At what point would this check run, and how would it help? (Presumably it wouldn't do anything to help for files you open from your OS file explorer (nautilus or whatever))

Comment 11

[Matthias Urlichs]

At what point would this check run, and how would it help?

Firefox gets into an infinite loop opening tabs. While doing so, it creates .part files for re-downloading the same file. I can see these files (they're empty) in /tmp/mozilla-* when this bug strikes.

Thus there is some data structure in Firefox which describes this process. I didn't check that this data structure contains the link that's to be opened but it'd surprise me a lot if it didn't. Thus it should be possible to scan the objects of this structure to ensure that the file isn't downloaded / opened again while the first download/open is still in progress.

This strategy would also help a lot when somebody clicks on a link twice by mistake (the well-known single/double click UI papercut) since nobody wants to download the same file twice in parallel.

Comment 12

[Negritas Sergiu, Desktop QA]

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 130.0a1(2024-07-08) on Ubuntu 22.04
Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

Comment 13

[unwell]

(In reply to Negritas Sergiu, Desktop QA from comment #12)

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 130.0a1(2024-07-08) on Ubuntu 22.04
Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

1. Only if it's the default profile
2. Yes
3. The issue exist with and without addons.

Comment 14

[unwell]

(In reply to Negritas Sergiu, Desktop QA from comment #12)

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 130.0a1(2024-07-08) on Ubuntu 22.04
Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

My reproduction surroundings want correct but I don't know how to change them.

1. Set Firefox to use system default application to open PDF's in the settings.
2. Go into about:config and search for pdfjs.disabled and set it to true.
3. If it doesn't try setting Firefox as the default PDF handler in Ubuntu.

Comment 15

[:Gijs (he/him)]

(In reply to Matthias Urlichs from comment #11)

At what point would this check run, and how would it help?

Firefox gets into an infinite loop opening tabs. While doing so, it creates .part files for re-downloading the same file. I can see these files (they're empty) in /tmp/mozilla-* when this bug strikes.

The thing is, I would not expect any "downloading" to happen for local files (and thus also no tmp file creation).