Chase uses a page with an <embed> to show its statements. This still gets loaded by acrobat rather than pdf.js.

I don't know if it makes sense to ship this when it doesn't work for (in my experience) a lot of PDFs

Actually I can't find a single place where I can see pdf.js render the pdf, acrobat always does it. Isn't pdf.js meant to replace acrobat where present?

My understanding is since Acrobat is a plugin, it has higher precedence over pdf.js to render PDF's. You need to disable Acrobat to use pdf.js. We've been thinking of ways to change this see bug 741517

Using PDF Viewer 0.3.175, <object> tags work but <embed> tags do not.

Embeded PDFs still don't open with PDF Viewer on latest Aurora(build 20120625042007)

This issue has been noted here https://github.com/mozilla/pdf.js/issues/1870 Apparently many PDF's in Canadian Government data bases use the embed tag for PDF's. I verified this with the latest pdf.js and the latest Aurora [20120706042008] on a test page I created here http://home.earthlink.net/~rvjanc/testpdf.html

Given bug 773397, tracking for FF16's release but not FF15.

(In reply to RobertJ from comment #7) > This issue has been noted here > > https://github.com/mozilla/pdf.js/issues/1870 > EDIT: Many PDF's in Canadian Government data bases use the embed tag for PDF's. I verified this with the latest pdf.js and FF15b on one of their pages http://www.collectionscanada.gc.ca/databases/census-1901/001013-119.03-e.php?sisn_id_nbr=7337&page_id_nbr=57401&interval=80

Brendan, it's been a couple of weeks with no activity on this bug. This is still on our radar for 16 so I'm assigning to you to determine who will be working on this bug and preparing a fix for uplift to Aurora.

I just re-tested this using the testcase I attached. 16.0a2 (2012-08-12) is broken 17.0a1 (2012-08-12) is working broken: http://hg.mozilla.org/mozilla-central/rev/1bbc0b65dffb working: http://hg.mozilla.org/mozilla-central/rev/e55638d4037a push log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1bbc0b65dffb&tochange=e55638d4037a I suspect Bug 745030 addressed this (though not without other regressions).

I tried this link http://www.collectionscanada.gc.ca/databases/census-1901/001013-119.03-e.php?sisn_id_nbr=7337&page_id_nbr=57401&interval=80 with the latest Aurora nightly 17a2 and it works great.

Embedded PDFs using the embed tag still don't display using the pdf.js viewer. Shouldn't we reopen this until this is completely implemented?

Mihaela, It depends. The pdf.js viewer/extension does not support this functionality. However internal (nightly) viewer shall support embed tags. If you have the extension installed, please remove/disable it and restart FF.

Comment #12 no longer applies. Tried http://www.collectionscanada.gc.ca/databases/census-1901/001013-119.03-e.php?sisn_id_nbr=7337&page_id_nbr=57401&interval=80 which uses the embed tag in FF17b and FF18a and neither work any longer. I do not have the pdfjs extension and in Applications (PDF) Preview in Firefox is displayed.

Update: I tried http://data2.collectionscanada.gc.ca/1901/z/z002/z000082266.pdf which is in an embed tag and it worked in FF17b. I'll look at that other link when I return from voting.

(In reply to RobertJ from comment #16) > Update: I tried > > http://data2.collectionscanada.gc.ca/1901/z/z002/z000082266.pdf > > which is in an embed tag and it worked in FF17b. I'll look at that other > link when I return from voting. IGNORE THIS. I WENT DIRECTLY TO THE LINK BYPASSING THE EMBED TAG. COMMENT #15 IS VALID, COMMENT #16 IS NOT

Was able to replicate the issue... re-opening

(In reply to Yury (:yury) from comment #14) > Mihaela, > > It depends. The pdf.js viewer/extension does not support this functionality. > However internal (nightly) viewer shall support embed tags. If you have the > extension installed, please remove/disable it and restart FF. I'm using the internal viewer in latest Nightly and Aurora builds, never had the pdf.js viewer extension. PDFs: * http://acroeng.adobe.com/test_files/embedded/embedded_weblink.html * https://bug738967.bugzilla.mozilla.org/attachment.cgi?id=621383 Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0, buildId: 20121105030642 Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0, buildId: 20121105042011

This issue keeps coming up on more sites. http://forums.mozillazine.org/viewtopic.php?f=38&t=2637851&p=12587507#p12587507 .

I'm increasingly finding this hole in our native PDF support disruptive to the user experience. bwalker@mozilla.com and bdahl@mozilla.com, what is your thinking on this? I've looked over the other PDF.js P1 and P2 bugs and this one seems like a higher priority than the others on that list.

(In reply to Asa Dotzler [:asa] from comment #22) > I'm increasingly finding this hole in our native PDF support disruptive to > the user experience. > > bwalker@mozilla.com and bdahl@mozilla.com, what is your thinking on this? > I've looked over the other PDF.js P1 and P2 bugs and this one seems like a > higher priority than the others on that list. I haven't run into many embed tag pdfs myself, so it hasn't been brought to my attention recently. We do have a patch to fix this, but it needs a bit more work. I'll bump the priority and we'll hopefully have it fixed soon.

Brendan, have you made any progress on this bug. This bug is on QA's shortlist of potential PDF.js blockers in Firefox 19.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #24) > Brendan, have you made any progress on this bug. This bug is on QA's > shortlist of potential PDF.js blockers in Firefox 19. I've gone over it with Yury and we have a plan to fix it. However, it involves changing some of the plugin overlay code that Yury worked on for a different project. Since it will be changing code outside of pdf.js to work, I don't think we'd want to uplift it since it probably needs a testing period.

(In reply to Brendan Dahl (Limited Internet Until 2/11) from comment #25) > Since it will be changing code outside of pdf.js to work, I don't think > we'd want to uplift it since it probably needs a testing period. I think I agree with that risk assessment. Do we have any indication of how common PDF embedding is? Are users able to work around this easily (preferably via infobar)?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26) > Do we have any indication of how > common PDF embedding is? Are users able to work around this easily > (preferably via infobar)? AFAIK the <embed> is the way to integrate the external stuff in Netscape (and recently in all HTML5 browsers). The <object> is element to represent external content. To be compatible with the all the browsers, the good web content authors used <object>...<embed..></object> constructs. Also, embedding is not that common in comparison with just regular reference to the PDF document (since most of people would want to save/print it). The workaround is to use: <object type="application/pdf" data="document.pdf"> ... fallback content ... </object>

See comment 9 with regard to many CA government sites using the embed tag. Also as noted in comment 12 at one time this was fixed (Aurora 17). Then somehow it was broken again as noted in comment 15. I have no idea how common using the embed tag is with a PDF in it; however, it is a legitimate syntax.

> See comment 9 with regard to many CA government sites using the embed tag. The code could be written by the same author. > Also as noted in comment 12 at one time this was fixed (Aurora 17). > Then somehow it was broken again as noted in comment 15. That might be true, but Firefox's plugins related code was changed a lot to protect the browser from outdated/unsafe plugins. Currently, we are working on restoring this functionality > I have no idea how common using the embed tag is with a PDF in it; however, it is a legitimate syntax. Yes, it is.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26) > I think I agree with that risk assessment. Do we have any indication of how > common PDF embedding is? Are users able to work around this easily > (preferably via infobar)? ADP (major US payroll provider) uses it on its page for viewing paychecks. I don't know of any end user workarounds, other than reverting to acroread :(.

(In reply to Scott Talbert from comment #30) > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26) > I don't know of any end user workarounds, other than reverting to acroread > :(. Scott, Not sure what you mean by "reverting to acroread"? FF19's PDF Viewer and Adobe Reader Plugin work side-by-side: the PDF viewer is used to view PDF resources and the plugin views the embedded stuff (like specified in https://bugzilla.mozilla.org/show_bug.cgi?id=738967#c12). WFM. Please make sure Readers plugin is enabled and "Preview in Firefox" is chosen in Preferences/Applications.

(In reply to Yury Delendik (:yury) from comment #31) > Not sure what you mean by "reverting to acroread"? FF19's PDF Viewer and > Adobe Reader Plugin work side-by-side: the PDF viewer is used to view PDF > resources and the plugin views the embedded stuff (like specified in > https://bugzilla.mozilla.org/show_bug.cgi?id=738967#c12). WFM. Please make > sure Readers plugin is enabled and "Preview in Firefox" is chosen in > Preferences/Applications. My bad, I wasn't aware that they could coexist. I'll give it a try when FF19 is released. Thanks, Scott

(In reply to Scott Talbert from comment #30) > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26) > > I think I agree with that risk assessment. Do we have any indication of how > > common PDF embedding is? Are users able to work around this easily > > (preferably via infobar)? > > ADP (major US payroll provider) uses it on its page for viewing paychecks. > I don't know of any end user workarounds, other than reverting to acroread > :(. Workaround that I've been using with ADP for a while: Go to pay statement page, see "A plugin is needed to display this content", go to Page Info (right-click, view page info OR click doorhanger thingy and select more information), go to Media tab, scroll down to the one grayed-out line that has type of "Embed", right-click and select copy, open new tab and paste URL. Voila, ADP pay statement as viewed by PDF.js -- no acrobat needed. :)

(In reply to Reed Loden [:reed] from comment #33) > (In reply to Scott Talbert from comment #30) > > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #26) > > > I think I agree with that risk assessment. Do we have any indication of how > > > common PDF embedding is? Are users able to work around this easily > > > (preferably via infobar)? > > > > ADP (major US payroll provider) uses it on its page for viewing paychecks. > > I don't know of any end user workarounds, other than reverting to acroread > > :(. > > Workaround that I've been using with ADP for a while: Go to pay statement > page, see "A plugin is needed to display this content", go to Page Info > (right-click, view page info OR click doorhanger thingy and select more > information), go to Media tab, scroll down to the one grayed-out line that > has type of "Embed", right-click and select copy, open new tab and paste > URL. Voila, ADP pay statement as viewed by PDF.js -- no acrobat needed. :) Not very user friendly. JMO

(In reply to Brendan Dahl from comment #25) > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #24) > > Brendan, have you made any progress on this bug. This bug is on QA's > > shortlist of potential PDF.js blockers in Firefox 19. > > I've gone over it with Yury and we have a plan to fix it. However, it > involves changing some of the plugin overlay code that Yury worked on for a > different project. Since it will be changing code outside of pdf.js to > work, I don't think we'd want to uplift it since it probably needs a testing > period. Do you ensure the nodes generated by PDF.JS are not available/accessible to the content when PDF.JS is loaded inside of an embed? See my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=840439#c7 Requesting feedback from :Yury as he worked on the overlay patch.

(In reply to Julian Viereck from comment #35) > Do you ensure the nodes generated by PDF.JS are not available/accessible to > the content when PDF.JS is loaded inside of an embed? > > Requesting feedback from :Yury as he worked on the overlay patch. PDF.JS content is not accessible from the main page and vice versa. See bug 776208

I think we should add a test in Mozilla-side to prevent the feature from breaking once again.

Fixed by bug 852981.

(In reply to Masatoshi Kimura [:emk] from comment #39) > I think we should add a test in Mozilla-side to prevent the feature from > breaking once again. Did anyone write the automated test for this? If not, I would like to work on it. Thanks!

(In reply to Masatoshi Kimura [:emk] from comment #40) > Fixed by bug 852981. This bug fix seems to bring about a regression discussed in bug 855666. Now Firefox 22.0a2 (2013-04-11) can not use Adobe Reader or other third-party PDF reader as a inline PDF reader unless users change the hidden settings in about:config and disable pdf.js.

I have Adobe Acrobat's plug-in and don't want it, so in about:addons I set it to Never Activate and it now shows "Disabled". To test I Googled "pdf.js test page" and one of the top results is https://www.farmersbankgroup.com/pdf-dot-js-test-page/ ... which doesn't work! Its <embed src="https://www.farmersbankgroup.com/wp-content/themes/farmersnationalbank/library/js/pdfjs/web/viewer.html?file=https://www.farmersbankgroup.com/wp-content/PDFs/1stQtr2015EarningsReleaseFINAL.PDF" width="680px" height="1080px"> produces the plug-in brick icon and "A plugin is needed to display this content." I don't see any errors. I don't have rights to reopen this bug. Mozilla/5.0 (Windows NT 6.0; rv:44.0) Gecko/20100101 Firefox/44.0

I can confirm what skierpage describes above in comment 43. I'm using Firefox 44.0a2 (2015-12-04) from Debian Mozilla team APT archive on my Debian Linux 64 bits system, and Flash is not installed on my system.

(In reply to skierpage from comment #43) > I have Adobe Acrobat's plug-in and don't want it, so in about:addons I set > it to Never Activate and it now shows "Disabled". To test I Googled "pdf.js > test page" and one of the top results is > https://www.farmersbankgroup.com/pdf-dot-js-test-page/ ... which doesn't > work! Its > > <embed > src="https://www.farmersbankgroup.com/wp-content/themes/farmersnationalbank/ > library/js/pdfjs/web/viewer.html?file=https://www.farmersbankgroup.com/wp- > content/PDFs/1stQtr2015EarningsReleaseFINAL.PDF" width="680px" > height="1080px"> > > produces the plug-in brick icon and "A plugin is needed to display this > content." I don't see any errors. I don't have rights to reopen this bug. > > Mozilla/5.0 (Windows NT 6.0; rv:44.0) Gecko/20100101 Firefox/44.0 I don't think the above is related to PDF viewer functionality. To invoke embedded PDF viewer, the EMBED content type shall be specified as 'application/pdf'. The "https://www.farmersbankgroup.com/wp-content/themes/farmersnationalbank/ > library/js/pdfjs/web/viewer.html?file=https://www.farmersbankgroup.com/wp- > content/PDFs/1stQtr2015EarningsReleaseFINAL.PDF" is "text/html". Also the type attribute is not specified as 'application/pdf', that's probably what throws plug-in brick icon (I'm sure you can create a simple test case without using complex library/js/pdfjs/web/viewer.html, but that's different bug). Is the right tag to use here IFRAME?