Hmm. I have mixed feelings about that. I wonder if it’s just more along the lines of a real vetting system than exclusivity. Also makes me wonder if there’s a way to sideload.
Anyway, interesting.
All right. Yeah. Other than being able to, turn off a bunch of those options, not show the thumbnails (if you wanted to), or show them, whatever, that’s pretty damn cool.
Context: Way back in February Dan and Ben were very “moustachioed” and I did a little bit of a play to embed a PDF. At the time I gave it away as a free project but took it down after. month.
Here is that little free project again and instructions are on page two of file. This opens an embedded PDF by button and/or picture. Hope this helps.
One thing I noticed when trying to view the PDF on my iPhone was that when the viewer opens, there are words “Open PDF”, which when clicked on, open the PDF in a browser window. The problem is that there is no way to return to the app. For a casual user they would feel “stuck” someplace and not know how to escape that open PDF window. The browser itself doesn’t show.
Am I doing something wrong in the setup of the viewer?
@MichaelDroste Yes. I am referring to the PDF Viewer. What happens on your phone when you display a PDF? On my desktops, the viewer works great. But on my phone I see the viewer window with words “Open PDF” (NOT seen when using my laptop). When I click on open PDF, the PDF opens and can be viewed. It is FULL Screen. I just discovered that if I swipe left from the very left side of the PDF, the window disappears and I am back to the webpage. This would not be intuitive for most users. Is there a setting that I am missing, like a close button or something that would let me exit the PDF Viewer?
Thanks!
Strange - will look on Friday- I can confirm that it is happening…
Sorry for that …
-Mike
Couldn’t Sleep - will post link to new files in 20 minutes all working - testing running checks
Here ya go all have been updated
Check new thread for latest updates
Since I’m using the PDF viewer inside of a modal, I’m assuming that this issue on mobile is not really going to be the same issue, or is that not the case? As in, what exactly is the difference here? Kind of curious to know.
From Claude:
the modal doesn’t change anything about the mobile PDF problem, because the modal is a container and the mobile problem is a renderer problem.
The actual difference is what paints the PDF, not where it sits:
<iframe>/<embed>/<object>— hands the file to the browser’s built-in PDF handler. iOS and iPadOS Safari paint page 1 only and never scroll; Android Chrome usually won’t render it at all and offers a download instead. A modal is just a positioned div with an overlay — the iframe inside it hits the exact same WebKit path it would in normal page flow. Z-index, fullscreen, and overlays are irrelevant to that engine.- PDF.js — JavaScript draws each page to a
<canvas>. No native PDF handler involved, so mobile works fine. - Direct link (
target="_blank") — hands off to the OS full-screen viewer. Scrolls and pinch-zooms everywhere.
So in the current build - already covered: touch devices get routed to the PDF.js path by the pointer: coarse / maxTouchPoints check before an iframe is ever created. Modal or not, no touch device sees the embed.
What the modal does introduce is a separate set of problems you’ll likely hit and mistake for the original bug:
- Zero-height init. PDF.js scales pages off the measured container. If the modal is
display: noneuntil opened, it measures 0×0 and pages render tiny or not at all. Fix: init or force a re-render after the modal is visible. 100vhon iOS. Safari’s URL bar makes100vhtaller than the visible area, pushing the close button and toolbar off-screen. Use100dvhwith a100vhfallback.- Body scroll lock. Locking the body on open can also kill scrolling inside the PDF pane on iOS.
overscroll-behavior: containon the scroll container, and no globaltouchmovepreventDefault. - Transform on an ancestor. If the modal animates in with a transform, any
position: fixedchild (sticky toolbar, page controls) positions against the modal instead of the viewport. Drop the transform when the animation ends. - Gesture collisions. Backdrop-tap-to-close and swipe-to-dismiss will swallow the PDF’s own pan/pinch. Scope the dismiss handler to the backdrop element only.
Stephen did you look at my sample project I posted for you?
Yes I did. I actually saw this earlier this year when it was posted. Fun project. One day I may get to a point of creating graphics like in your project. Thanks!