I’ve been using okular to open pdf files in Firefox for years. A recent
upgrade switched on Firefox’s internal viewer, which annoyed me when I
went to look at my on-line bank statement.
I immediate dug out my notes on how to disable it again, went to
about:config, and set the pdfjs.disabled toggle to true.
Then I set my Edit->preferences->applications pdf document to “use okular”.
Logged back in to my bank, and okular opened a blank page?!? {expletive deleted}
Looked at Firefox’s download list, and found that the filename was
“StatementDisplay.asp”. Found that in /tmp, and tried manually feeding it to
okular. {Blank page} {More expletives deleted}
Went back to Firefox, tried right-clicking on the bank statement link.
Didn’t get any choice to download as a pdf.
Went back to about:config, and re-enabled the pdfjs.
But okular still opened with blank content.
Went back into edit->preferences->applications and removed okular from the pdf
settings. But couldn’t find any setting that would now actually use the
pdfjs to open the statement. {MANY expletives deleted}
In frustration, I used opera to login to my bank, and it opened the same
link with okular as “StatementDisplay.pdf”
{still deleting expletives}
I use Firefox for my online banking because I think it’s more secure.
I really don’t want to use it’s internal document viewer.
I have a strong preference to using okular for that.
But now I can’t use either in Firefox to view my online bank statement.
You have to start with studying the link which is supposed to point to your document, and what is actually pointing to.
I strongly suspect it’s not pointing directly to a PDF, it’s pointing to an ASP.NET page which is typically a combination of server-side and client-side scripting and html… not a PDF.
That would likely be why Okular is displaying a blank page… it doesn’t know how to read ASP.NET.
If you inspect the contents of the ASP.NET page, you might find the link to your PDF or it might contain server side code for serving the PDF… If the latter, then you may be out of luck… that is why server side code is used, to hide functionality from the client.
> You have to start with studying the link which is supposed to point to
> your document, and what is actually pointing to.
> I strongly suspect it’s not pointing directly to a PDF, it’s pointing to
> an ASP.NET page which is typically a combination of server-side and
> client-side scripting and html… not a PDF.
>
> That would likely be why Okular is displaying a blank page… it doesn’t
> know how to read ASP.NET.
>
> If you inspect the contents of the ASP.NET page, you might find the link
> to your PDF or it might contain server side code for serving the PDF…
> If the latter, then you may be out of luck… that is why server side
> code is used, to hide functionality from the client.
Sounds familiar. Ie, it just happened to me.
I noticed yesterday similar behaviour with some invoices: click on the
PDF, and it opened inside FF, with the internal viewer, which I strongly
dislike. I tried several alternative links, same results. The links were
long and complex, no way I could just download the PDF from there. Yes,
deleting expletives here, too.
But what you explain makes sense, now.
However, one of the buttons in the FF internal PDF viewer is “save PDF”,
which does save it locally with the correct filename (ie, the invoice
number). At least in my case, so I’m relatively happy.
That would likely be why Okular is displaying a blank page… it doesn’t know how to read ASP.NET.
Except that Opera wasn’t the one feeding a blank page to okular.
That was Firefox. Which at first opened the document in the internal viewer. Until I disabled it.
Then it was Firefox that couldn’t derive the pdf from the “asp.net”, and instead fed a downloaded .asp file to okular
Then it was Firefox that wouldn’t let me reactivate the pdfjs internal viewer, or at least wouldn’t derive the pdf content for it anymore.
Opera, simply fed the end result of the derived pdf content to okular.
In my case, when I tried to switch back to the FF internal, it wouldn’t open the document anymore.
Fortunately Opera still works properly with same link. Though since I always clear the history, when
I logout of a banking session, I find it anoying to have to close all the search result windows, on-line
dictionaries, and forum sesions I tend to have open in opera.
It would appear that on Aug 31, Carlos E. R. did say:
> On 2015-08-31 08:36, jtwdyp wrote:
>> {expletivedeleted}
> Well, reading your post, I guess I will not disable the internal PDF
> reader
Don’t worry to much about that. I don’t believe it was this mornings reboot,
{this ain’t windodo after all} I might have looked for the ‘preview in FF’
option to the about:preferences#applications setting, before I re-enabled
pdfjs in about:config or something. But I’m able to use the internal viewer,
if I enable it, in BOTH ‘about’ dialogs
> > It bugs me that firefox won’t do it anymore.
>
> Try create a new (alternative) profile for FF, and see if it works.
Did that, and replicated the same problem.
But I was referring to opening the document IN Okular… I mean if Opera can
do it, surely the Firefox devs can.
I suppose that pdfjs is how the Firefox devs want me to do it. But I found
out something that bugs me. The problem is ALL in the filename! I took a look
at the /tmp/StatementDisplay.asp with less. Then I compared it with the
StatementDisplay.pdf, that Opera had fed Okular with. Next I went back to my
bank with Firefox. {AFTER disabling the pdfjs and setting FF to use Okular
again.}
Then when Okular opened that “Blank” document named StatementDisplay.asp, I
told Okular to save the file to a directory of my choosing. “save As” was
grayed out, but the other choice “Save copy as” let me correct the filename
from “StatementDisplay.asp” to “StatementDisplay.pdf”, which subsequently
displayed well when I typed “okular StatementDisplay.pdf” at a bash
prompt…
It’s like the Firefox devs, want to make it hard to use an external viewer,
instead of the internal one, that they’ve spent so much time on. {sigh}
