ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.1030 Redux

[VistaLover]

As an addendum to my previous post, Mozilla do host (on GitHub) "on-line" editions of their PDF.js lib, one targeting "current" browser engines: 

https://mozilla.github.io/pdf.js/web/viewer.html

and another targeting "legacy" browser engines: 

https://mozilla.github.io/pdf.js/legacy/web/viewer.html

Neither of the two works on Ch86/87-based browsers (and on St52) to display the "C0801E.pdf" file, 

https://mozilla.github.io/pdf.js/legacy/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf

https://mozilla.github.io/pdf.js/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf

while BOTH do when loaded in Ch121-based latest Supermium-v121-hf  ... Yes, the browsers "we" use here are more "legacy" than what Mozilla even thought of  ...

Edited February 27 by VistaLover

[Anbima]

When I open the following PDF, 360Chrome wants to save it:
https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0818A.pdf

The following PDF is displayed directly in 360Chrome:
https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0805A.pdf

Is it possible to set all of them to be displayed in 360Chrome?

[VistaLover]

45 minutes ago, Anbima said:

Is it possible to set all of them to be displayed in 360Chrome?

... With respect , you did not make an effort, it seems, to follow what I have already posted in a previous post  ; whether a PDF on-line URI will generate a "Save As" file download prompt (case 1 in your previous post) or the PDF file will be auto-downloaded in the background and rendered+displayed inside the browser's Native PDF Viewer (case 2 in your previous post) is something beyond the user's (initial) control, in fact it's a server-side configuration: the PDF file on the hosting server has been configured with a content-disposition value, by the server admins...

In case 2, the value is "inline"; this (alongside a suitable Content-Type header) instructs the browser to handle the PDF file "in-line", i.e display it inside a tab via the native viewer (or via a PDF reader plugin, where applicable); in case 1, the value is "attachment"; this instructs the browser to simply "download" the PDF file to disk, for storage.

I have already mentioned an extension in my previous post which changes the "attachment" Content-Disposition value to "inline", but the problem with such an extension is it's not specific to PDF files; other types of files you may want to download to disk (e.g. images, audio, video, etc.) will attempt to be displayed directly in the browser (if the browser is able to render them natively); that's why I said I only enable that extension at will...

Edited February 27 by VistaLover

[Anbima]

2 minutes ago, VistaLover said:

... With respect , you did not make an effort, it seems, to follow what I have already posted in a previous post 

Sorry, but some of it was too complicated for me, so I didn't understand it.
But now I've got it. Thanks.

[VistaLover]

On 2/25/2024 at 7:09 PM, VistaLover said:

you want the older v0.0.4, which is still at MV2, for 360EE...

Fortunately, that one has been salvaged by crx4chrome  :

https://www.crx4chrome.com/crx/299038/

[Mathwiz]

On 2/26/2024 at 10:29 AM, VistaLover said:

... "no sense" is probably only "applicable" to frequenters of these threads, on "legacy" browser engines  ; I can assure you that the web designers of that Spanish site did NOT, even for a mere second, think of "backwards compatibility" ; they're probably "trained" to expect each and every eventual user of their service to be running the latest Chrome/Firefox/Safari, where the original "issue" you reported (and generated many additional posts here) is simply non-existent....

It is undoubtedly true that those Web designers don't care one whit about compatibility with any browser other than the latest Chrome/Firefox/Safari! But that's not quite what I meant when I said it made "no sense" for a Web site to host pdf.js on their site.

What I meant was, they went to some extra trouble to do this, but got no apparent benefit from going to that trouble! It didn't make their .pdf pages readable on any of the "big three" browsers, since they all can display .pdf's without any help; it didn't speed up displaying of .pdf's; it broke any NPAPI plugins their Firefox users might be using (admittedly, the likelihood of them caring about that is only slightly higher than the likelihood of them caring about us Chromium 86 users); and it didn't save the site any bandwidth (to the contrary, it costs them additional bandwidth to download pdf.js to every site visitor who clicks one of their .pdf links)!

So why did they bother? The only reason I can think of is the same one you suggested:

On 2/26/2024 at 6:01 PM, VistaLover said:

.. one "probable" answer why "enganchesaragon.com" choose to self-host an instance of the Mozilla PDF.js lib to display the PDF files "they" serve is: "They" prefer it over the native-PDF-viewer implementation on users' (mostly Chrome-based) browsers....

Firefox snobs? It sounds crazy, but as Sir Arthur Conan Doyle said through his fictional character Sherlock Holmes, "when you have eliminated the impossible, whatever remains, however improbable, must be the truth."

[NotHereToPlayGames]

7 hours ago, Mathwiz said:

It is undoubtedly true that those Web designers don't care one whit about compatibility with any browser other than the latest Chrome/Firefox/Safari!

I technically don't agree with this 100%.  Not saying it's not true, just saying the entire picture cannot be painted with this one brush and this one brush stroke.

I'm not referring to .pdf's but "web browsers" in general.  The constant push for "new and improved" isn't being led by the "web designer", it's being led by the hype and propaganda behind "security".

"Use our browser!  It's more secure then theirs.  Just look at our upgrade rate relative to theirs, we find and fix vulnerabilities faster then they do.  Use our browser!"

Paraphrasing, of course.

 

In regards to .pdf's, totally and completely agree!  It makes NO SENSE for a web site to host a "viewer" when Mozilla-based started embedding a built-in .pdf viewer in 2011 and Chrome-based started in 2010.

One uses HTML5 and .js.  The other uses C++.

This would have been Firefox 5 and Chrome 7.  Where are we at now?  I've lost track because they both update 7 times a day (exaggerating, of course).

[VistaLover]

20 hours ago, Mathwiz said:

But that's not quite what I meant when I said it made "no sense" for a Web site to host pdf.js on their site.

... FTR, you did not say (rather, write  ) the "no sense" part; you actually "said": 

On 2/26/2024 at 3:32 AM, Mathwiz said:

But I still can't understand why one would host pdf.js on a Web page

;  the "no sense" "argument" was brought up by Anbima: 

On 2/26/2024 at 5:33 PM, Anbima said:

In my opinion, it makes no sense to integrate a separate PDF viewer here.

... and it was this "argument" by him the portion of my reply you quoted above was addressing ; just as a disambiguation  ...

20 hours ago, Mathwiz said:

it broke any NPAPI plugins their Firefox users might be using

... If I'm not terribly mistaken , Mozilla were the first to do this thing in their own browser, Firefox, many years ago already: 

https://bugzilla.mozilla.org/show_bug.cgi?id=1269807

https://www.ghacks.net/2015/10/08/mozilla-announces-the-end-of-npapi-plugins-in-firefox/

https://support.mozilla.org/en-US/kb/npapi-plugins

https://support.mozilla.org/en-US/questions/1270346

... Unless you were referring to the Firefox-based forks "we here" use, which just consolidates my prior argument  : 

On 2/26/2024 at 6:29 PM, VistaLover said:

only "applicable" to frequenters of these threads, on "legacy" browser engines 

Best regards  ...

Edited March 4 by VistaLover