2

In an application I've made, there is a PDF Viewer. It's simply just an IFrame with a PDF Blob set as the src attribute.

Now I'm wondering if I can somehow access the scroll position of that IFrame?

I tried to access the contentWindow.scrollY of the IFrame, the contentWindow.window.scrollY and may more and am now running out of ideas.

With another IFrame that has a srcDoc attribute (HTML), accessing the contentWindow.scrollY works fine in the same project.

Also, currently, I'm just working with chrome, I would appreciate if someone has an answer that works across different browsers.

UPDATE: When I open the application in Firefox I can actually see an error, when I try to scroll the PDF IFrame:

SecurityError: Permission denied to access property "scrollTo" on cross-origin object

I was already suspecting a security reason, I guess chrome just doesn't report that? Still, I'm wondering how I could solve this because the PDF is generated locally to a Blob URL, so it's not really a cross-origin object

josias
  • 1,326
  • 1
  • 12
  • 39
  • did you try to get the scrollTop of the iframe? check mdn docs for it https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop i – Saleh Almohtaseb Feb 20 '20 at 13:43
  • Yes, tried that and unfortunately, it doesn't work :/ – josias Feb 20 '20 at 14:02
  • try this answer https://stackoverflow.com/questions/1852518/how-to-get-scrolltop-of-an-iframe – Saleh Almohtaseb Feb 20 '20 at 14:06
  • 1
    I've seen this answer already, but I'm not using jQuery and I think jQuery does probably do the same thing. What's weird is that I can actually get the scrollY prop of the iframe window when I open the iframe's inspector tools. But getting it from contentWindow just doesn't want to work. Maybe some privacy settings of chrome? – josias Feb 20 '20 at 14:29
  • _“so it's not really a cross-origin object”_ - “generated locally” probably doesn’t matter much here, the fact is still that it is a blob URL, and so it is considered as being from a different origin. – CBroe Feb 20 '20 at 14:42
  • @CBroe I see the problem. I just wonder if there is some way to solve this. Can I put the pdf data inline instead of converting it to an url? – josias Feb 20 '20 at 16:15
  • Data URI instead of blob would probably have the same problem, `srcdoc` is for HTML only, and other than that, I wouldn’t know how to inline it. Where do these PDFs come from, can’t they be loaded from the server? – CBroe Feb 21 '20 at 07:18
  • @CBroe I fetch the PDFs from an endpoint, just like the HTML too for the other iframe – josias Feb 21 '20 at 07:28
  • Meaning, AJAX in the background - and that is what making the use of a blob to get it to display necessary? Is that endpoint cross-origin? If not, it might be possible to just automatically submit a form populated with the necessary data instead (if it needs to be a POST request), and have its target set to the iframe. – CBroe Feb 21 '20 at 07:30
  • Hmm I don't follow where you are going with this. I'm working w/ react and simply run `fetch("url")` with some parameters (POSt). How would a Form affect how it works? I store the returned data in a PDF Blob because I don't know an alternative. The endpoint accepts cross-origin, but after the data is fetched and stored in a Blob, I don't think JS has any clue were it came from. I think that the PDF viewer itself is just treated as cross-origin resource but I'll need to check that theory, no matter where the data comes from. – josias Feb 25 '20 at 08:36

0 Answers0