1946143 - 'Try it Now' for new PDF editor, opens the PDF in Adobe instead of the Firefox Browser if Firefox is not the default PDF handler

Status: NEW

(www.mozilla.org :: General, defect)

Description

[Shawn]

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

Steps to reproduce:

Firefox update, reveals new option to edit PDF's in Firefox, but upon hitting the 'Try it Now' button provided, it opens the PDF in Adobe where no editing is allowed. It will not open the PDF within the Firefox browser as alluded to in your new update window.

Actual results:

The supposed addition of the ability to edit PDF's within Firefox is not working, and opens the file in my free edition Adobe app on my computer instead.

Expected results:

Hitting 'Try if Now' should open the sample PDF you provided, within Firefox and allow for edits??

Comment 1

[BugBot [:suhaib / :marco]]

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

[Marco Castelluccio [:marco]]

Shawn, this is happening because you set Firefox to open PDFs in Adobe. If you want, you can change to open them in Firefox by changing the setting in the "Applications" section of the Firefox settings.

Comment 4

[Marco Bonardo [:mak]]

Could you please let us know if Marco's suggestion in comment 3 helped?
More specifically, how is PDF set in General / Applications? Does changing to "Open in Nightly" solve the problem?

That said, maybe the suggestion to Try the new feature should only be presented if pdfs are handled by Firefox. Calixte, would that be reasonable?

Comment 5

[Calixte Denizet (:calixte)]

Could we just open this specific pdf in Firefox whatever the default handler is ?
In the case where Firefox isn't the default handler, we give an opportunity to the user to maybe change their mind.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Calixte Denizet (:calixte) from comment #5)

Could we just open this specific pdf in Firefox whatever the default handler is ?

Not easily (the code has already far too many edge cases to handle), we think it would likely be easier to not suggest trying the feature checking the pdf handler.
Maybe the message could change in the case and suggest how the user can set Firefox as pdf handler.

Comment 7

[Marco Castelluccio [:marco]]

The what's new page is just a "normal" web page: https://www.mozilla.org/en-US/firefox/135.0/whatsnew/.
So, is there really anything we can do here?

Comment 8

[Shawn]

(In reply to Marco Castelluccio [:marco] from comment #3)

Shawn, this is happening because you set Firefox to open PDFs in Adobe. If you want, you can change to open them in Firefox by changing the setting in the "Applications" section of the Firefox settings.

OK, thank you, I changed the default PDF viewer to "always ask"....and now I have the option to open in Firefox or Adobe. I wondered if that was why it kept defaulting to Adobe, but hadn't navigated settings in awhile to change anything. I did look in settings, but couldn't find it, so thanks.

Also thought the 'Try it Now' button might override the default settings as a one off, obviously not.

Case closed. :)

Comment 9

[Marco Castelluccio [:marco]]

I wonder if we can build another page where we have an iframe with the pdf, this might be enough to make sure the PDF is opened inline in Firefox. Then the WNP page would just link to that page.
WDYT Calixte?

Comment 10

[Calixte Denizet (:calixte)]

I just tried on mac with https://demo.jmix.io/ui-samples/sample/iframe-pdf and if an external pdf handler is set then the pdf isn't opened anymore in Firefox so unfortunately I don't think it's the solution.

Comment 11

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 12

[:Gijs (he/him)]

I don't think this is something we can fix in the file handling code. It either needs a change in the webpage, or in the targeting / UI tour / exposed telemetry bits, so punting to PDF for further triage.

Comment 13

[Marco Castelluccio [:marco]]

I'm not sure there's anything that can be done on the webpage, given the iframe didn't work.
Targeting only users with PDF enabled would maybe be feasible, but then we'd be missing a very valuable audience that we actually do want to target.

I guess the exception in the file handling code would be the only thing that matches what we want to do. If that's not feasible, I suggest we close this as WONTFIX.

Comment 14

[:Gijs (he/him)]

OK. I thought about this a bit more.

From what I gather the intent is that we show users how awesome PDF.js is and that it can do everything they can do in Adobe reader or whatever. That makes sense.

I think anything we do here we should not limit to mozilla.org, and ideally feel comfortable doing to all PDFs displayed in this way (that is: content-disposition: inline, and/or without one entirely), for users who have either set pdfjs.disabled (maybe?) or configured the default action for PDFs to be something other than showing the PDF inline (maybe a second decision being whether we are comfortable doing it for people who have "always ask" vs "always open with [Adobe/Edge/NitroPDF/whatever]).

But given that, I think we can improve the user flow for everybody. When websites send PDFs like this, even if I have PDFs set to open in [other app], it's not unreasonable to show an inline prompt. We would probably want to develop this behind some kind of flag. But it would be neat if inside the frame there was simply a question and a button or two, along the lines of:

example.com wants to show a PDF. Show here or open with [default app] ?

where "show here" would hand the PDF to PDF.js and the other one would start a download.

The main issue with this, IMO, is that we probably can't show this prompt to the user every time with no ability to say "no, I really mean it, stop messing and just open Adobe/whatever". We can make it one-time, or add a checkbox for this purpose ("Always ...") or come up with some heuristic or whatever. Something of a product call, probably.

But I think this is almost entirely possible within the existing PDF.js framework. We can still start the download into a blob and instead of showing the "full" PDF.js UI we can show the choice to the user, and either load the PDF.js bits later or create a blob download with the original URL and so on, the same way PDF.js does today when you save from the viewer.

Comment 15

[:Gijs (he/him)]

I mean, the other thing, which is maybe less work but more... assertive and arguably (it's a bit messy, see. e.g. bug 1612351 which requests more or less this!) less respectful of user choice, would be to always default to PDF.js for inline PDFs (without asking) and only defer to the default viewer for Content-Disposition ones, a la bug 1811830. Though we'd probably still need an about:config way for people to indicate "no but I really always want Adobe/Edge".

Comment 16

[Marco Castelluccio [:marco]]

We might also want to prompt users asking them to always use Firefox for PDFs, after they have tried it. Not sure what's the best way to do that.

BTW, I've just found out that in cases where people set another reader as default, we still use PDF.js for <embed>, so for this specific page we could just use <embed>.
This should be more common than pdfjs.disabled, so we could start with that (though we'd have to fix bug 1655525 first).

Comment 17

[Marco Castelluccio [:marco]]

The solution to bug 1655525 will actually be very similar to what Gijs proposed, so perhaps we should just directly do that.