PDFObject Fails to Detect that FIrefox on Linux Supports PDFs

[christianmemije]

PDFObject fails to detect that Firefox supports PDFs, on Linux specifically. In Firefox on Linux, the MimeTypeArray does not include 'application/pdf', so supportsPdfMimeType is not set to True. It is a Firefox on Linux issue, but I was wondering if there was a way that PDFObject could bypass this confusion.

[pipwerks]

Hello Christian

Thanks for the heads' up. To be honest, I haven't tested on Linux, just Mac OS X and Windows (and mobile devices). Odd that Firefox doesn't include application/pdf mime type. I will take a look when I get a chance.

Thanks

[huan086]

It's broken on Windows too. Seems to be related to this change

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

My Firefox navigator.mimeTypes only has "application/x-silverlight" and "application/x-silverlight-2" now

Related issue https://bugzilla.mozilla.org/show_bug.cgi?id=840439

[pipwerks]

Hmm it's affecting Firefox on OS X now too. PDFObject says inline PDFs aren't supported (because PDF mime type is not found) even though PDF.js is available. Not sure what to do here, will need to look into alternatives (or cross fingers the Mozilla folks revert to expected behavior).

[mallikarjuna909]

Basically.. i picked PDFObject mainly for hiding/Removing the toolbar. But even i can see the toolbar, this is particularly for "Firefox".

Are you sure is this working in Firefox? If Yes send me solution.

Here is my trial

var options = { pdfOpenParams: { view: 'Fit', scrollbars: '0', toolbar: '0', statusbar: '0', navpanes: '0' } }; PDFObject.embed('MyPdf.pdf', ".box-content", options);

[pipwerks]

mallikarjuna909, your issue is unrelated and you already have an issues thread for your issue.

[edisoncks]

I have the same issue here. Built a web site using PDFObject. When I view the page in Firefox on Windows there is no problem, but when I try to view the same page in Firefox on Ubuntu PDFObject will report that inline PDF is not supported.

[gh372029002]

I was in mac firefox 49.0.2， Prompt me "This browser does not support inline PDFs. Please download the PDF to view it: Download PDF"

[matmiranda]

PDFObject fails to detect. Problem: FireFox(50.0.2) on Windows 10.

Image: https://s17.postimg.org/jisqlp0cv/75_2016_12_07.jpg

Open your FireFox with : https://pdfobject.com/examples/detection.html not work

[c-simpson]

Here's the discussion of the missing mimetype issue on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1293406

I'm seeing it on FF Developer Edition 52.0a2

[pipwerks]

Thanks, I've added my 2 cents to the discussion there.

[gh372029002]

Yes my question is out theremac for Firefox.

原始邮件 发件人:matmirandanotifications@github.com 收件人:pipwerks/PDFObjectPDFObject@noreply.github.com 抄送:胡文峰372029002@qq.com; Commentcomment@noreply.github.com 发送时间:2016年12月7日(周三) 23:29 主题:Re: [pipwerks/PDFObject] PDFObject Fails to Detect that FIrefox onLinux Supports PDFs (#93)

PDFObject fails to detect. Problem: FireFox(50.0.2) on Windows 10. Open your FireFox with : https://pdfobject.com/examples/detection.html not work — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[pipwerks]

PDFObject is not working in Firefox for Mac or Linux, and now it appears Windows as well. Apparently Mozilla removed the application/PDF MIME type from Firefox's navigator.mimeTypes object.

Until they restore support for it, or provide an alternative, there's not much I can do without a significant rewrite.

Since reworking PDFObject to get around Mozilla's change would require a significant refactoring, I want to wait and see if Mozilla will restore the MIME type before making any changes.

[c-simpson]

Philip - thanks for all your work on this,

[matmiranda]

Yes, browser firefox not support PDF. I've checked if your browser has PDF support here. Result: Browser has "application/pdf" in navigator.mimeTypes array: false. Is returned false.

[gh372029002]

Hello so that users can be compatible with Word 2003, we have to modify the default.Docx generated for Word 2003 *.doc how should I do it?

http://www.phpdocx.com/en/forum/default/topic/392 http://www.phpdocx.com/en/forum/default/topic/392

[pipwerks]

@gh72029002 that has nothing to do with PDFObject or this issue (#93).

[lebbe]

I fixed this issue in my fork of PDFObject 1.0 like this:

https://github.com/lebbe/PDFObject/commit/5807b5b3522b4f50737600c1e6f8bd63e3b7d6ac

Combined with setting the inner text of <object> to a "This browser does not support PDF" (or something similar), this text will show instead of the PDF if the firefox-user has turned of PDF-rendering. I have done this outside of pdfobject.js in our project, but it would be safe to do this within pdfobject when the browser is firefox.

I might start with pdfobject 2.0 and reapply my patches in my fork. Would you then accept push request @pipwerks ? It includes ipad-, pdfjs- (as a user-installed plugin) and firefox-support.

[huan086]

@lebbe if I'm not wrong, Firefox mobile does not have PDF.js built in. So we will need to detect for Firefox mobile when sniffing user agent

[lebbe]

@huan086 embedded PDF on mobile devices? Rad.

That would either way not be any problem, if you fill the <object> with a text explaining that the browser doesn't support showing embedded PDF. In Firefox (at least) this text is shown if no PDF is loaded, but is hidden if a pdf is loaded to <object>.

Please take note that this only applies to PDFObject 1.0. 2.0 uses <embed>, I don't know how this behaves. When my employer gives me the time, I am going to look into updating to PDFObject 2.0 and apply my patches for firefox/ipad/user-installed pdfjs again.

(It is simply not an option to remove pdf support on these devices, for instance we have a huge customer base of electricians who use iPads to register different forms etc, who are depending on my ipad-hack. Most use cases are a simple A4 sheet of paper, so the problem with lack of pdf dimensions on iPad doesn't apply to us.)

[pipwerks]

@lebbe

PDFObject 1.x uses <object>, which enables fallback text (text placed between the <object> tags, such as <object>PDFs not supported</object>).

PDFObject 2.x uses <embed>, because PDFObject's JS would normally only insert an <embed> element if PDF support is detected. Otherwise the original HTML would remain in place, such as <div class='mypdf'>If you can read this, PDFs are not supported</div>.

You can skip the JS and use pure HTML markup if you like -- the generator at pdfobject.com will provide you with a clean <object> element.

[pipwerks]

Sorry accidentally closed. :D

Still waiting on Mozilla to clear up the confusion.

[goatandsheep]

My fork of the project works well on Firefox. It's a bit dusty, but I should be able to clean it up by next week if it's important

[pipwerks]

@goatandsheep What changes are in your fork?

[TheCthulhuKid]

@pipwerks Potentially stupid question (I barely know js): Could we not just check the user agent? return (/mozilla/i.test(navigator.userAgent.toLowerCase())) or something?

[pipwerks]

@gileadslostson The prevailing wisdom is that you should avoid user agent sniffing whenever possible, as it is usually fragile and hard to maintain (here's a good primer on the subject). The more reliable solution is feature detection, which is what we're doing by looking for the application/pdf MIME type.

Looking for application/pdf in navigator.mimeTypes used to work fine in Firefox, until the folks at Mozilla decided to put theory ahead of pragmatism when they recently removed support for the entire navigator.mimeTypes array. They say it isn't in the spec, and duly removed it, despite it being implemented in all major browsers (including Firefox) for years. Thus many JS-based utilities, like PDFObject, are now breaking in Firefox.

You ask: "Could we not just check the user agent?"

My answer: I have tried everything I can to avoid this, because it is considered a bad practice, and I can't believe Mozilla will force our hand into going back to practices they themselves decry in their own MDN documentation (see "Don't UA-sniff"). I have been as obstinate in my stance that they should continue to support navigator.mimeTypes as they have been when they say it isn't in the spec. But after months of waiting, I see absolutely no movement on Mozilla's part -- frankly, I don't think they're even discussing the subject anymore -- so I will probably start working on an update that includes a sniff for Firefox.

Bear in mind, when sniffing for Firefox, we will be assuming Firefox ships with PDF support via PDF.js. If they ever remove PDF support, we'll have no way of knowing. I will have to include a conditional statement for people who might be using an older version of Firefox that shipped before PDF.js was added, to ensure they don't get stuck in limbo. (Thankfully the auto-update feature in Firefox will make this less of an issue than it would have been 5-10 years ago.)

Stay tuned.

[TheCthulhuKid]

@pipwerks Thanks for the reply! I will read through the primer. It is definitely strange that they removed it.

[runes83]

Any news on the Firefox problem?

[zslabs]

@pipwerks 👋 Just wanted to chime-in that while it looks like there was a little activity around the Bugzilla report, I think at this point a small workaround for browser-sniffing FF would be a great; since we can with almost 100% certainty assume that the auto-update should kick-in.

[TheCthulhuKid]

@zslabs it is easy to implement for yourself as a stop-gap measure until something more official comes along. (From my comment above): return (/mozilla/i.test(navigator.userAgent.toLowerCase()))

[pipwerks]

Yeah I think Mozilla's silence has spoken volumes. What a shame.

@gileadslostson, a search for /mozilla/i will return positive in many browsers, not just Firefox. See https://gist.github.com/enginnr/ed572cf5c324ad04ff2e. A good example of why user agent sniffing is generally avoided when possible.

I have been very busy lately and haven't had as much time as I'd like to research the best workaround. Happy to hear proposals if anyone has them (preferably clean, concise, and targeting recent versions of FF).

Thanks

[zslabs]

Wanted to get your thoughts on this idea -- right now https://github.com/pipwerks/PDFObject/blob/master/pdfobject.js#L81 controls whether a PDF can be inlined or not. While we do have the option of download the lib, saving it to the repo and editing it from there; ongoing updates may be missed (such as the beauty of npm). Would you be open to exposing this logic as an option when initializing the lib (with a way to reference the built-in defaults and extend)? That way, we can keep the integrity of the current-state of the app and provide an override for whatever support we would like to inject.

[zslabs]

Also -- the regex explained in this post seems to be a bit more isolated to FF (even if it is version 1+; which I'd hope we can assume for the sake of sanity that would not be an issue) since this deals with feature detection, not sniffing.

// Firefox 1.0+
// Firefox's API to install add-ons: InstallTrigger https://developer.mozilla.org/en-US/docs/Web/API/InstallTrigger
var isFirefox = typeof InstallTrigger !== 'undefined';

If my previous comment about extending the compatibility doesn't sound great, then maybe an option to enable forcing Firefox specifically (with the above function) could work? Disabled by default to not cause regressions, but available for other users to consume if needed.

[pipwerks]

@zslabs Can you please submit a different issue thread for the proposal above? It would help if you have a specific use case so I can better understand what you're trying to achieve. Thanks!

Regarding InstallTrigger, despite what was stated in the StackOverflow post, this type of proprietary feature detection is fragile. Feature detection is ideal when you intend to use that particular feature, not when you're trying to sniff out browser brand. For example, it makes perfect sense to sniff for LocalStorage support if you intend to use LocalStorage. But when used purely for detecting browser brand/version, it can lead to problems down the road. A lot of sites broke when Microsoft deprecated document.all and window.attachEvent in IE11. As we have learned the hard way, Mozilla is more than willing to drop support for a long-standing feature based purely on their ideals and without much regard for real-world impact.

Regarding InstallTrigger, Mozilla themselves say "Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future."

As much as I hate user agent sniffing, it may be more reliable.

[reberinformatik]

Is there anything planned to fix this issue or should I search for a workaround? Any timeframe?

[bcalik]

Any news on this? Is there any way to force it? because Firefox can actually display.

Edit: Ok I can confirm this guy's fork is working well: https://github.com/rhinogram/PDFObject/commit/ba4a15af8aa7b8494d8df48d42ca6f863992215e

[pipwerks]

I am working on adding browser sniffing to PDFObject.

[pipwerks]

Merry Christmas everyone, I have revised the script and posted to the development branch. I would really appreciate it if you could give it a try.

https://github.com/pipwerks/PDFObject/blob/development/pdfobject.js

This update works as a drop-in replacement, with userAgent sniffing for Firefox (v19 or greater, since PDF.js first shipped with FF 19: "PDF.js is part of Firefox since version 19").

This version also includes a new 'assumptionMode' option (disabled by default). If assumptionMode is enabled, PDFObject will check to see if the browser is modern. If yes, PDFObject will assume PDF rendering is supported, will not check for MIME type support, and will just go ahead and write the <embed> to the page.

The hard (and surely controversial) part is determining how to quantify 'modern browser'. For PDF rendering purposes, it just so happens that every major browser which supports the Promises JavaScript object coincidentally provides a PDF rendering engine. Chrome, newer Firefox, newer Safari, Edge, newer Opera. No IE, no older versions of FF, etc.

Why Promises? I spent a lot of time looking for common threads between the browsers to find a 'proper' way to define the 'modern' browser. But the browser world is fluid, constantly changing. And with anti-fingerprinting techniques on the rise, it will just become harder and harder to perform true feature detection for plugins and PDF support. As I researched, I noticed the adoption of Promises (as well as some other JS features) coincided with PDF rendering support. It's not perfect -- I believe some older browsers like Chrome rendered PDFs before Promises were natively supported -- but I think this is a suitable compromise.

Honestly, it's hacky as hell, and I'm not thrilled about it. But if all browsers go the anti-fingerprinting route of Firefox, we will not have many options. The best practice is to never assume, never sniff, and only do pure feature detection, but in the case of PDF rendering, Mozilla has taken that off the table. If we ever get to that point, PDFObject will still work fine if you enable assumptionMode. It's a failsafe of sorts.

Constructive feedback and testing results appreciated.

(Note: iOS 11 Safari still does not support rending inline PDFs, so the proper testing result for iOS Safari is a "your browser does not support PDFs" message.)

[halldororn]

Just tested on Firefox, Chrome, Internet Explorer and Microsoft Edge on desktop (windows 10) and the development version works as intended. All browsers except Internet Explorer show support for PdfObject with assumptionMode turned off.

[pipwerks]

Thank you for testing, @halldororn

[manrevlob]

Tested on Firefox(old and new version), chrome and IE. Thanks you.

[ppazos]

On Firefox 62.0 Linux: your browser doesn't support inline PDFs.

[pipwerks]

@ppazos Did you try the beta (dev branch)? Production (master branch) does not support FF due to issue described above. I just tested the beta in FF 62 on Ubuntu 18 and it worked fine.

[ppazos]

@pipwerks I'm testing the online examples, not the code: e.g. https://pdfobject.com/examples/full-browser-explicit.html

prints "This browser does not support inline PDFs. Please download the PDF to view it: Download PDF"

[pipwerks]

Thanks. The online examples are not using the beta and are known to not work in FF.

On Wed, Oct 3, 2018 at 9:51 AM Pablo Pazos Gutiérrez < notifications@github.com> wrote:

@pipwerks https://github.com/pipwerks I'm testing the online examples, not the code: e.g. https://pdfobject.com/examples/full-browser-explicit.html

prints "This browser does not support inline PDFs. Please download the PDF to view it: Download PDF"

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pipwerks/PDFObject/issues/93#issuecomment-426712175, or mute the thread https://github.com/notifications/unsubscribe-auth/AASWFk3H_vVSC2BGd_lQEEKfirOejuNWks5uhOr_gaJpZM4JsUqW .

[pipwerks]

I have pushed the dev branch to production, including NPM. Closing this issue. Thanks for all of the input and testing, I appreciate it. And sorry for the delay.

[shenghan97]

Still not working on firefox 64 on mac. In the html code it simply injects <embed class="pdfobject" src="pdf/sample-3pp.pdf" type="application/pdf" style="overflow: auto; width: 100%; height: 100%;"> which is identical to what it injects to chrome. Not sure if this means pdfobject failed to detect firefox to try to use pdfjs instead.

[pipwerks]

It works in Firefox for Mac. If you're encountering problems, please open a new issue and be sure to include sample embed code and preferably a link for testing.