Why can't Firefox load page http://www.cslewisinstitute.org/webfm_send/770 ?
I would like to write to the site to suggest fixing the code (which, among other problems, seems to include a recursive embed), but am stumped on two issues:
a) Why other browsers have no problem with the page; b) Why Firefox does not even load the page code for analysis.
Can someone help with this?
All Replies (8)
Works for me. It's just a pdf file.
Please explain the problem in detail. What happens? What is the exact error messages?
TyDraniu said
Works for me. It's just a pdf file.
That's a good clue.
Check your setting for PDF files. If you want them to open in a Firefox tab, use "Preview in Firefox". If you want them to open in Adobe Acrobat or another external application, specify that other application. The setting that does NOT work is to specify opening using firefox.exe, because that will create a loop.
More info:
With apologies for some ignorance on my part, thanks all for your replies. Fred, the simple answer to your question: nothing -- that's what surprised, because the URL box was correct ("http://www.cslewisinstitute.org/webfm_send/770") but page source (Ctrl-U) was blank. [Because the page source -- which I got from a different browser -- is only a few lines, it would be informative to list it here, but I have not be able to figure out how to show it in this reply, with this editor.]
TyDraniu and Jscher, thanks for quickly identifying the practical part of my problem: It was delivering a PDF file, and somehow (I don't recall doing it) I had changed PDF handling from "Acrobat (Default)" to "Save File" (with no further action) so that I did not see the result; that's on me.
Still I see reason for being misled, based on three factors:
1) The recursive embed source:
src="http://www.cslewisinstitute.org/webfm_send/770"
I have never seen the page's own URL being the target of an embed statement, and could not imagine how a browser is supposed to parse that structure. I still don't know. If anyone knows, I would be grateful for that information.
2) Without the URL identifying the file as it normally would ("../770.PDF"), one does not expect to check PDF handling.
3) Firefox's PDF handling options give no info in this situation:
- "Preview in Firefox" shows the PDF file - but Page Source (for the page that yielded the file) is not available.
- "Save File" saves the file, but Page Source is blank. [With no identification of a PDF file, this was the situation that confused me.]
- "Use Acrobat" opens appropriately, but Page Source is blank.
It would be nice if ANY of Firefox's PDF handling options would give the page source (which I got from a different browser) for the web page which embedded the file. If anyone knows how to get that source from Firefox, I would be grateful for the education.
Again, thanks for all the replies.
Hi John, there's no page source for PDF files, just as there is no page source for Word documents or ZIP archives.
jscher2000 said
... there's no page source for PDF files, just as there is no page source for Word documents or ZIP archives.
That's of course true of PDF or any (even, say, HTML) file that is delivered by (embedded in) a page; my request was to see the source of the page that delivers (embeds) the file. In that regard, it was probably stupid of me to look for a choice of PDF handling that might help to see the page source, but I would have done so regardless of the file type.
As I mentioned, I got that page source immediately from another browser [Microsoft Edge]. I was disappointed that I could not do so from Firefox.
Thanks for your reply. This gives me a chance to apologize again for the original question, which was not well-formed.
I see, for that PDF in Edge, Ctrl+u calls up the developer tools. The comparable developer tools view in Firefox compared with Edge can be called up using either:
- F12
- "3-bar" menu button > Web Developer > Inspector
- (menu bar) Tools > Web Developer > Inspector
You'll notice that Firefox's PDF viewer breaks down the PDF and re-renders it as HTML, so the rendered source tree looks completely different from the Inspectors in Edge and Chrome, which take more of a plugin approach in their PDF viewers. Not sure whether that is helpful.
jscher2000 said
I see, for that PDF in Edge, Ctrl+u calls up the developer tools. The comparable developer tools view in Firefox compared with Edge can be called up using either:
- F12
- "3-bar" menu button > Web Developer > Inspector
- (menu bar) Tools > Web Developer > Inspector
I knew that, but thanks for taking care to explain the options.
You'll notice that Firefox's PDF viewer breaks down the PDF and re-renders it as HTML, so the rendered source tree looks completely different from the Inspectors in Edge and Chrome, which take more of a plugin approach in their PDF viewers.
Yes, when the option to"Preview in Firefox" is chosen, the breakdown into nested DIVs body(outerContainer(mainContainer(viewerContainer(viewer)))))
and then the breakdown of each page into
canvasWrapper(textLayer(<text_DIVs>))
is instructive about the PDF format. For that matter, isn't that what PDF plugins do (less transparently) for other browsers?
I appreciate that Firefox is almost always (a) as transparent as possible and (b) as accommodating as possible of user preferences -- in every way, but particularly in this context, with a table of choices for handling downloaded application files. Moreover, I know I need to learn to efficiently use the tools Firefox provides [on my to-do list].
And I appreciate Firefox for many other reasons not relevant to this issue. But I wish it provided a way to capture the source of the page before an embedded file is downloaded (and, depending on user preference, rendered as a new HTML file). Lesser browsers do so.