-
Notifications
You must be signed in to change notification settings - Fork 986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PDFObject Fails to Detect that FIrefox on Linux Supports PDFs #93
Comments
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 |
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 |
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). |
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 = { |
mallikarjuna909, your issue is unrelated and you already have an issues thread for your issue. |
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. |
I was in mac firefox 49.0.2, |
PDFObject fails to detect. Image: https://s17.postimg.org/jisqlp0cv/75_2016_12_07.jpg Open your FireFox with : https://pdfobject.com/examples/detection.html not work |
Here's the discussion of the missing mimetype issue on Bugzilla: I'm seeing it on FF Developer Edition 52.0a2 |
Thanks, I've added my 2 cents to the discussion there. |
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.
|
PDFObject is not working in Firefox for Mac or Linux, and now it appears Windows as well. Apparently Mozilla removed the 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. |
Philip - thanks for all your work on this, |
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. |
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>
|
@gh72029002 that has nothing to do with PDFObject or this issue (#93). |
I fixed this issue in my fork of PDFObject 1.0 like this: Combined with setting the inner text of 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. |
@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 |
@huan086 embedded PDF on mobile devices? Rad. That would either way not be any problem, if you fill the Please take note that this only applies to PDFObject 1.0. 2.0 uses (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.) |
PDFObject 1.x uses PDFObject 2.x uses You can skip the JS and use pure HTML markup if you like -- the generator at pdfobject.com will provide you with a clean |
Sorry accidentally closed. :D Still waiting on Mozilla to clear up the confusion. |
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 |
@goatandsheep What changes are in your fork? |
@pipwerks Potentially stupid question (I barely know js): Could we not just check the user agent? |
@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 Looking for 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 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. |
@pipwerks Thanks for the reply! I will read through the primer. It is definitely strange that they removed it. |
Any news on the Firefox problem? |
@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. |
@zslabs it is easy to implement for yourself as a stop-gap measure until something more official comes along. (From my comment above): |
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 |
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. |
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.
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. |
@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 Regarding As much as I hate user agent sniffing, it may be more reliable. |
Is there anything planned to fix this issue or should I search for a workaround? Any timeframe? |
Any news on this? Is there any way to force it? because Firefox can actually display. Edit: |
I am working on adding browser sniffing to PDFObject. |
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 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.) |
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. |
Thank you for testing, @halldororn |
Tested on Firefox(old and new version), chrome and IE. |
On Firefox 62.0 Linux: your browser doesn't support inline PDFs. |
@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. |
@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" |
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 < ***@***.***> 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
<#93 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASWFk3H_vVSC2BGd_lQEEKfirOejuNWks5uhOr_gaJpZM4JsUqW>
.
|
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. |
Still not working on firefox 64 on mac. In the html code it simply injects |
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. |
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 toTrue
. It is a Firefox on Linux issue, but I was wondering if there was a way that PDFObject could bypass this confusion.The text was updated successfully, but these errors were encountered: