Open Bug 1906126 Opened 1 year ago Updated 1 year ago

Print to PDF text not selectable and not readable. Mozilla's Flatpak Firefox.

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Version:
Firefox 139
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: compost.idu_20230512_521658, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: flatpak)

Attachments

(6 files)

Print-to-pdf---Firefox-127---Screenshot-448.png
22.59 KB, image/png
Details
Molybdenum - Wikipedia.pdf
973.72 KB, application/pdf
Details
FF---Standard---Molybdenum---Wikipedia---2025-04-26.pdf
1.54 MB, application/pdf
Details
FF---Standard---Borax---Wikipedia---2025-04-27.pdf
1.69 MB, application/pdf
Details
FFN---Default---Borax---Wikipedia---2025-04-27.pdf
1.82 MB, application/pdf
Details
FFN---Default---Molybdenum---Wikipedia---2025-04-27.pdf
1.57 MB, application/pdf
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Steps to reproduce:

  1. Using Firefox 127, log-in ebay.ca or ebay.com Then open any eBay "messages" webpage.

  2. Using Firefox, navigate to Option ---> Print. Alternatively, press Ctrl-P keys

  3. Using the "Destination" field. Select "Print to PDF" option

  4. Open the PDF file you created above. Most of the webpage text is not readable, not selectable, not usable. Looks like somehow the HTML text was automatically converted to extremely low resolution images. Those are the challenges. The needed end result is that HTML text print as selectable text into the PDF file.

Using Firefox 127 from https://flathub.org/apps/org.mozilla.firefox
Using Debian 12 Bookworm.

This challenge can not be reproduced with Ungoogle-Chromium/Chrome. It can only be reproduced with Firefox/LibreWolf.

Related

Temporary workaround

  1. Using Firefox, navigate to Option ---> Print. Alternatively, press Ctrl-P keys

  2. Using the "Destination" field. Select "Print to PDF" option. Under "Format", select the option “Simplified”.

  3. Open the PDF file. The same text is not selectable. But the images were not all printed as this is a simplified view of the webpage. So it seems that somehow the content of the printed webpage affect the "Print to PDF" output.

Actual results:

Most of the webpage text is not readable, not selectable, not usable. Looks like somehow the HTML text was automatically converted to extremely low resolution images. Those are the challenges.

Expected results:

The needed end result is that HTML text print as selectable text into the PDF file.

This screenshot shows the challenge into the output PDF file. Text is both not readable and not selectable. Also, because it is an image. It used 10 to 100 times more storage space.

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

Component: Untriaged → Printing: Output
Product: Firefox → Core

This challenge can also be reproduced when using Firefox to print to PDF this Wikipedia page at https://en.wikipedia.org/wiki/Molybdenum

See that attached PDF file

This challenge can be reproduced with many other websites. Such as, but not limited to, Wikipedia.Org. But only some of their pages. Not all their pages.

For those interested to reproduce this. Using the Firefox PDF output window. Under "Format" group. Leave the Firefox default "Original" option selected. Do not select the other "Simplified" option.

We were able to reproduce this challenge with two different devices. And different versions of Firefox. Both with and without add-ons/modules. This change can be reproduced all the way back to Firefox version 14.0.1 Which was released more than 10 years ago.

Duplicate of bug 1487467 perhaps?

Thanks @longsonr :) I added a comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1487467#c5

@longsonr :) bug 1487467 is for Ubuntu. This bug 1906126 is for Debian 12 Bookworm.

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
See Also: → 1487467
Summary: Print to PDF from Firefox. Text not selectable and not readable. Text is image. → Print to PDF from Firefox. Text not selectable and not readable. Text is image. Debian.

The code is the same on Linux whether it's Ubuntu or Debian or any other Linux flavour.

See Also: → 620916

The code is the same on Linux whether it's Ubuntu or Debian or any other Linux flavour.

Yes and no. Yes the code of Firefox is the same. But Firefox's input and output to its OS dependencies often vary between Ubuntu and Debian. I mean during the creation of PDF file, the code of the libraries, other dependencies varies, and the versions for those dependencies varies too. For example, but not limited to, CUPS, GL, graphic acceleration, Mesa, WebGL, etc.

I'm not a developer. But my guess is that this challenge is somehow related to how Firefox display images in a page. Because using the exact same Firefox and device, using the 3 steps below, we are not able to reproduce this challenge. In these 3 steps below, notice that the only difference is that Firefox's "Simplifies" is selected. Instead of "Original". This means that somehow, this challenge is likely related to how Firefox display images in a page. Before the page is sent to the OS for the creation of the PDF file.

Steps to not reproduce and narrow down the source of the challenge:

  1. Using Firefox go to https://en.wikipedia.org/wiki/Molybdenum Navigate to Option ---> Print. Alternatively, press Ctrl-P keys.

  2. Using the "Destination" field. Select "Print to PDF" option. Under "Format", select the option “Simplified”. Do not select the Firefox's default "Original" settings.

  3. Open the PDF file. The same text is not selectable. But the images were not all printed as this is a simplified view of the webpage. So it seems that somehow the content of the printed webpage affect the "Print to PDF" output.

In my last comment, the 3rd steps needs to read: "Open the PDF file. The same text is NOW selectable. But the images were not all printed as this is a simplified view of the webpage. So it seems that somehow the content of the printed webpage affect the "Print to PDF" output."

You mentioned:

Using Firefox 127 from https://flathub.org/apps/org.mozilla.firefox

We do occasionally run into flatpak-specific rendering issues -- see the many dependencies of bug 1278719. I don't think this particular bug is a known issue, but it's possible there's some flatpak-specific weirdness here. Would you mind testing the "official" .tar.bz2 distribution of Firefox Nightly and see if that gives you the same issue? (You could test official Firefox 127 release, too, but it's better/easier to test the Nightly version (https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly ), since it will launch & run independently from your regular flatpak-installation's Firefox sessions, whereas multiple versions of 127 release will try to "gracefully" launch windows in your existing browsing session which makes it harder to be sure which flavor you're actually running.)

For what it's worth, I tested this bug with Nightly and also with Firefox-127-as-a-flatpak, on Ubuntu 22.04 (my local environment), printing https://en.wikipedia.org/wiki/Molybdenum to "Save to PDF" with default settings, and haven't been able to reproduce any issue yet. (The text looks nice and is selectable for me, in the resulting PDF.)

(In reply to Francewhoa (Francois Carpentier) from comment #10)

Yes and no. Yes the code of Firefox is the same. But Firefox's input and output to its OS dependencies often vary between Ubuntu and Debian. I mean during the creation of PDF file, the code of the libraries, other dependencies varies, and the versions for those dependencies varies too. For example, but not limited to, CUPS, GL, graphic acceleration, Mesa, WebGL, etc.

(This is true in general -- but specifically for Firefox's print-to-PDF pipeline, there shouldn't be much in the way of distro-specific behavior-differences; Firefox brings along its own PDF printer, and I don't think that part touches CUPS at all. But yes, there does seem to be something specific to your system so far that's involved here; we'll try to get to the bottom of what that is. Testing official-Nightly is a good first start towards ruling things out. Thanks!)

Francois, could you please try this with an official Nightly version, as mentioned by Daniel in comment 13? That could help in narrowing down what's happening here. Thank you.

Flags: needinfo?(compost.idu_20230512_521658)

Resolving as 'incomplete' due to lack-of-response for now; so far we haven't been able to repro.

It's possible this is config-specific (perhaps requiring flatpak + additional specific details), but it's hard to know what's required to trigger it at this point.

Reporter: if you happen to see this and you're still able to reproduce the issue, please see above comments & add a note here if Bugzilla lets you, or feel free to file a new bug with info requested above. Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---

This comment cancel and replaces my today's previous comment.

Thanks all for your replies and questions. Appreciated :)

This is to confirm that this challenge can still be reproduced. Using latest Firefox 137.0.2 (64 bits).

Steps to reproduce:

  1. Using Firefox 137.0.2 (64 bits) https://flathub.org/apps/org.mozilla.firefox go to https://en.wikipedia.org/wiki/Molybdenum Navigate to Option ---> Print. Alternatively, press Ctrl-P keys.

  2. Using the "Destination" field. Select "Print to PDF" option. Under "Format", select the default option “Original”. Do not select the "Simplified" other option.

  3. Open the PDF file. The text is not selectable. In comparison, for other Wikipedia's pages, they printed just fine. Text is selectable. So it seems that somehow the content of the printed page affect the "Print to PDF" output. Also, notice that the PDF file is significantly larger than usual. About 1.5 Mb. Instead of the expected 0.8 Mb.

In my future comment below, I will attach the today April 26th, 2025 PDF file which shows this challenge.

Using this on device 1:

• Firefox latest version from Arch Linux repository

• Arch Linux latest version

• KDE Plasma latest version

Using this on device 2:

• Firefox 137.0.2 (64 bits) from https://flathub.org/apps/org.mozilla.firefox

• Debian Bookworm 12

• GNOME 43.9

Using these same steps to reproduce in this comment #18, this challenge can be reproduced with this page at https://en.wikipedia.org/wiki/Borax

For comparison, using these same steps to reproduce in this comment #18, this challenge can be reproduced with those four Firefox powered browsers:

  1. Firefox 137.0.2
  2. LibreWolf 137.0.2-1
  3. Waterfox 6.5.6
  4. FireDragon 11.25.0-1

Same challenge can not be reproduced with:

  1. Ungoogled-Chromium 135.0.7049.114-1

@dholbert, I'm in progress of testing today's nightly per your comment #13. My ETA is within the next 4 hours to publish my result here.

Flags: needinfo?(compost.idu_20230512_521658)

@dholbert, Using the steps to reproduce in comment #18, this challenge can not be reproduced with:

Is there a Flatpak Firefox Nightly version I could test with? I searched at https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly but found none.

As you know, this challenge can still be reproduced with the four Flatpak versions listed in comment #21

This attached file shows that using this other page at https://en.wikipedia.org/wiki/Molybdenum this challenge can't be reproduced. Using FFN per comment #23.

Between FF and FFN, the PDF final file size is almost the same. Interesting.

Thanks for those results! Good to know that this doesn't reproduce in Nightly.

I have no idea if there's a flatpak version of Nightly, offhand.

The next useful thing to test would be the official Mozilla-provided Firefox release version from e.g. https://www.mozilla.org/firefox/new/

I suspect that will work just fine (given that Nightly works just fine and this code hasn't changed recently). If so, that would indicate that this is definitely a Flatpak-specific issue, which is useful to know for diagnosis purposes.

(tentatively classifying as flatpak-specific for the time being, since this has been reproducible for the reporter in Flatpak for many releases and is not reproducible for the reporter in the "stock" nightly build).

Blocks: flatpak
Severity: -- → S4
Flags: needinfo?(compost.idu_20230512_521658)
Keywords: flatpak
Summary: Print to PDF from Firefox. Text not selectable and not readable. Text is image. Debian. → Print to PDF text not selectable and not readable. Mozilla's Flatpak Firefox.
Version: Firefox 127 → Firefox 139

This is to confirm that this challenge can be reproduced with the latest Mozilla's Flatpak Firefox 139.0.1 (64-bit). Which was released by Mozilla 6 days ago.

Using the same steps to reproduced as up above

Below is the same as above. But with details for those interested.

This ticket is about the official Mozilla's Flatpak release at https://flathub.org/apps/org.mozilla.firefox or at https://archive.ph/8oG7s Which is both verified and maintained by Mozilla.

Manifest at https://hg.mozilla.org/mozilla-central/file/tip/browser/installer/linux/app/flatpak

This is a note to myself: ID_7M32A9R3 ---> ID_D2S2A4V7

Thanks @dholbert 🙂 For both your reply and adding the flatpak tag. My replies are below.

this has been reproducible for the reporter in Flatpak for many releases and is not reproducible for the reporter in the "stock" nightly build).

Have you tried reproducing this challenge using the official Mozilla's Flatpak Firefox from https://flathub.org/apps/org.mozilla.firefox and the steps to reproduce above in this ticket? The present version of Mozilla's Flatpak Firefox is 139.0.1

For those not familiar with Flatpak, the Mozilla's Flatpak Firefox can be installed on most Linux distributions without making any change to already install Firefox Nightly. Because it is fully sandboxed. Assuming that the Flatpak engine is configured properly.

I have no idea if there's a flatpak version of Nightly, offhand.

My understanding is this Mozilla's Flatpak Firefox is based on the Mozilla's Nightly. Source at https://hg-edge.mozilla.org/mozilla-central/file/tip/browser/installer/linux/app/flatpak

In other words, Mozilla's Flatpak Firefox is not Nightly. But based on Nightly. For example, the last Mozilla's Flatpak Firefox was built 5 days ago and release 6 days ago. In comparison, as you know, Nightly is release daily. So a few days difference. You're welcome to educate me if I missunderstand this.

This is a note to myself: ID_7M32A9R3 ---> ID_D2S2A4V7

(In reply to Francewhoa (Francois Carpentier) from comment #27)

This is to confirm that this challenge can be reproduced with the latest Mozilla's Flatpak Firefox 139.0.1 (64-bit). Which was released by Mozilla 6 days ago.

Thanks! Given that non-flatpak Firefox Nightly 139 didn't reproduce the bug (per comment 23), whereas flatpak-flavored Firefox release 139 does reproduce the bug (comment 27), I think we're safe to treat that as likely-confirmation that this is a flatpak-specific issue (rather than e.g. a bug that we'd had in previous firefox releases which was fixed in Nightly, as could have hypothetically the case before we had this confirmation about flatpak-flavored-139 being affected).

So: that's helpful organizationally to know what at-what-layer things are broken here. Hopefully folks familiar with Firefox's flatpak sandboxing can pick this up at some point.

(In reply to Francewhoa (Francois Carpentier) from comment #28)

Have you tried reproducing this challenge using the official Mozilla's Flatpak Firefox from https://flathub.org/apps/org.mozilla.firefox and the steps to reproduce above in this ticket? The present version of Mozilla's Flatpak Firefox is 139.0.1

I haven't personally, no.

I have no idea if there's a flatpak version of Nightly, offhand.

My understanding is this Mozilla's Flatpak Firefox is based on the Mozilla's Nightly. Source at https://hg-edge.mozilla.org/mozilla-central/file/tip/browser/installer/linux/app/flatpak

It looks like you're right, yeah -- thanks for finding that!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: