Closed jakenvac closed 7 months ago
~I will do some follow up work to support chrome, but I'm happy to do this as a separate PR if this current firefox fix is acceptable as is.~
Update: I don't think we can programmatically focus the pdf body in chrome's reader.
@ItsEthra Thanks for taking the time to engage with this PR. It's odd that you don't experience the same behavior. I'm wondering if it's OS specific? I'm running MacOS.
Yes it might be a Mac os only thing. I'm on arch linux. Though it can also be that I'm using Firefox nightly.
I've tried firefox nightly on my machine and I still have the same issue so I would chalk it up to the OS. No hard feelings if you don't want to merge - It's always frustrating when the cause of an issue isn't immediately clear. "Fixes" can end up being hacks.
Otherwise, if you would like to merge, I've noticed the check is failing, but I'm not very familiar with nix. I'm not sure what's going on with the cargo.lock (or why it's changed on my end) as I only changed the HTML file.
Honestly I don't know nix either but updating lock file seems to help so i don't really care. Thanks for the contribution.
When using keyboard navigation, focusing the browser window does not focus the PDF iframe and thus using Up/Down do not scroll the pdf. Currently, to work around this, I press tab when I switch to my browser to focus the pdf.
This isn't something that is noticeable if you navigate to your browser window by clicking in the frame as it inherently focuses the PDF (because that's what was clicked on).
This PR adds three small changes:
.focus()
is called on thetarget
element.DOMContentLoaded
listener is added to focus the PDF on first load.I've tested this in firefox and chrome:
Update: I don't think it's possible to fix this for chrome.