Pressing "back" button on mouse when viewing a PDF goes forward to a random(?) note

[isaacchua]

Some mouses and keyboards have a dedicated back and forward button. Generally, using them to navigate with the Pane Relief plugin works as it should.

However, when a PDF document is displayed in a pane, even if there is no forward history, pressing back takes the pane forward to a seemingly random note from the vault. This is not correct behaviour.

This does not happen when the Navigate Back hotkey is used.

OS version: Windows 10 Pro 20H2 19042.1586 Obsidian version: 0.14.5 Installer version: 0.13.31 Plugin version: 0.0.24

[pjeby]

Where are you pressing the back button? When I click mine on the PDF, nothing happens, except if I click it repeatedly fast enough the PDF reloads. But no other navigation happens. If I click in the frame around the actual PDF iframe, it navigates correctly.

I notice you say "some mouses and keyboards" but not what you're specifically using or doing. Is this a keyboard button or mouse button? If keyboard, how is it mapped in software? (Most keyboards with extra buttons have some kind of software installed to control the functions they perform, often on a per-app basis.) If it's a mouse, often there is similar software as well, though it's a bit less common. Knowing how these buttons are mapped is important, because it's possible they're sending something that the built-in PDF support interprets differently. Obsidian uses Electron's built-in PDF support, which takes over a lot of browser-related functionality within the display area, and there really isn't anything Obsidian or a plugin can do to change how it acts (without replacing the PDF support entirely).

[isaacchua]

I am using a Logitech MX Master 3 mouse. I am pressing the Back button on the mouse. When I press it in .md notes, it works as expected. When I press it on .pdf files, it goes forward to a random note.

I don't think it has to do specifically with the PDF support. Without Pane Relief enabled, pressing Back on a PDF file will go back to the previous note or pane based on the default history in Obsidian.

[pjeby]

If it was solely Pane Relief involved, I should be able to reproduce it. But on my Windows machine with a Logitech M10 I get no response from clicking forward or back on a PDF, so I don't really know what I can do for you here.

Pane Relief replaces the window.history element for the main window, but it does not do this for iframes, and Obsidian displays PDFs in iframes. Pane Relief monitors mouse events in the main window, but does not receive them for events in iframes. So whatever is happening as a result of your mouse clicks, it's the result of how the iframe handles them -- Pane Relief cannot change the behavior of a click it isn't being told about.

If you use your mouse's back button on the pane header (where the filename appears) or in the area outside the iframe, what happens?

[isaacchua]

I tried it on the pane header and it works as expected. This means somehow the iframe is sending something else. Will probably need to involve Licat in this.

[pjeby]

He's previously stated that the PDF viewer is self-contained and there's little to nothing he can actually do about what it does. I think that it should probably be replaced with the pdf.js library, but that's something a plugin could be written for and so is not really a high priority for Obsidian core.

[isaacchua]

I frankly don't think it's an issue with the viewer. It is an issue with the Pane Relief plugin, since it is adding another entry to the pane's history somehow when I press Back. Literally, the number on the back button on the Obsidian title bar increases by 1 instead of decreasing by one, and the forward button increasing by 1.

[isaacchua]

Moreover, the back and forward buttons on the mouse work as expected when Pane Relief is not enabled, even when the focus is on the PDF and not the pane title. Logically reasoning, the issue lies with Pane Relief.

[pjeby]

The point isn't where the issue lies, it's that I can't fix what I can't understand or reproduce. I can't reproduce the behavior you're describing, even though I'm on Windows with the same app and installer versions as you. The only thing back and forward ever do for me on a PDF in Obsidian is to occasionally cause the iframe to reload. My forward/back counts don't change and the pane doesn't navigate, ever. Are you able to reproduce this by adding a PDF to the sandbox vault and enabling only Pane Relief and no other plugins?

[isaacchua]

I didn't test with the sandbox vault, but I tested with all plugins off, restarted Obsidian, then turned on Pane Relief.

Starting from a note and clicking on a link to a PDF, it goes there. Title bar shows "1" on back and nothing on forward. But the back button doesn't work. HOWEVER, the forward button works and it goes to some other random note.

The title bar shows "2" on back and nothing on forward now. There is no more forward history for the pane. Pressing back goes back to the PDF, and the title bar shows "1" on back and "1" on forward.

Pressing forward sends me to a random PDF. It shows "2" on back and nothing on forward. Forward doesn't work, but back takes me to a random note, with "3" on back and nothing on forward.

Pressing back takes me back to the PDF and it shows "2" on back and "1" on forward.

Pressing forward takes me to another random PDF and it shows "3" on back and nothing on forward.

Pressing BACK takes me to a random note and it shows "4" on back and nothing on forward.

I wish there was some way to trace this because it is so weird.

[pjeby]

It definitely sounds weird to me as well. At least we've ruled out other plugins being involved. Offhand, it sounds like the forward and backward clicks on the PDF are sending you to notes that Pane Relief is then recording as though they were regular link clicks (which is why the back number keeps growing and back takes you back to the PDF).

My first guess was that the seemingly random selections were coming from Obsidian's native history mechanism, but from what I can tell that history isn't saved between sessions (unlike how Pane Relief does it), so if you've restarted Obsidian, the random navigation shouldn't be coming from there.

I tried a different vault than the one I normally use and have been able to reproduce one aspect of this: if I click forward and then back on a PDF I can get it to go back to the previous page (before the PDF) while acting as if it's navigating forward (i.e. the forward count goes away and the backward count goes up by one).

However, the only way that I can reproduce it is if I have Pane Relief off, then navigate some, and turn Pane Relief back on. If I just start Obsidian with Pane Relief on to begin with, I can't get any odd behavior. In fact, I can produce seemingly random navigation on purpose, by starting Obsidian without Pane Relief, navigating to various documents, and then starting Pane Relief. When I use the forward/back buttons on a PDF pane, Obsidian then navigates as I would expect for the native history I created before enabling Pane Relief.

So it appears the issue is that the PDF viewer is triggering history actions on the native history, as I initially guessed. If that is the problem, however, it would seem that you should not be having the problem if you leave Pane Relief on across restarts and don't ever navigate with it off. (That is, you should have no navigation happening when you click on PDFs, not "random" navigation.)

Is this consistent with your experience? That is, if you have Pane Relief on, then exit Obsidian, start Obsidian again, and then immediately attempt to reproduce the issue without turning off Pane Relief, do you still get random navigation?

[isaacchua]

Hmm, my Obsidian had updated itself to 0.14.6 and I can no longer use back and forward on a PDF pane. In fact, it has stopped responding to keyboard shortcuts even, when in focus. Something had fundamentally changed.

Anyway, I noticed that if my mouse cursor is over the pane title, even if the pane title is not in focus, I am able to go back or forward with the mouse normally. That could mean that previously, something was capturing these events when the cursor was over the pane, and that something is no longer there.

To your question: previously I had restarted Obsidian many times with the Pane Relief plugin on and it made no difference to the strange navigation experience. Unfortunately, I can't test it again in this version.

[pjeby]

I would expect that if the pane title is in focus, the keyboard nav commands should work normally as well.

Pane Relief captures all forward/back clicks (mouseup to be precise) that are on the main document. PDFs are iframes, not part of the main document, so Pane Relief has never captured such clicks on the body of a PDF. Instead, what was happening (at least on my test that successfully reproduced something similar to your problem) was that the browser engine was detecting the navigation attempt on the iframe, then telling the window as a whole to go back or forward since the iframe had no history. The window navigation thus triggered was the browser nav for the window, not Pane Relief's patched/emulated version of it, causing weird navigation to apparently-unrelated places.

All I can say regarding your experience here is that your vault appears to be behaving as expected: i.e. clicks on a pdf pane should never have had any effect at all, but clicks over the area that's not in the iframe should navigate normally. Keyboard nav should work as long as the iframe does not have focus -- e.g., if the pane header gets focus.

[isaacchua]

Thanks. It is strange that I was able to use back and forward on those iframes in the first place. I'll close this issue and open another one if I encounter another issue.