#1009 Keystrokes in single page and presentation mode

[yuggib]

In presentation mode (OS 10.10 Yosemite), the up key makes the page go forward, while the down key makes the page go back. This affects the behavior of the laser pointer (Kensington) as well, so the left arrow goes forward and the right backwards (in other viewers, both Preview and Adobe reader the behavior is normal). Is it possible to fix this in some way?

[Christiaan Hofman]

OK, I am confused. First of all, we don't handle left/right arrow. Apple does. But are you talking about left/right arrow on the keyboard, or left/right on the remote? I don't know what Kensington does. Wherever we do handle left/right arrow keys, (as in Presentation mode for key events and remote control events) we always do Next Page for right arrow. Again, all other events are handled by Apple. So what you say makes no sense to me.

[yuggib]

In presentation mode, keyboard up arrow goes forward and down arrow goes
back (in skim). In preview and Acrobat reader, up arrow goes back and down
goes forward, as before. This behavior is reflected on the remote, where
the forward button goes back and vice versa (on skim), while on acrobat and
preview is ok (so I am guessing the buttons are mapped to up and down keys).

[Christiaan Hofman]

This makes absolutely no sense. We don't map any up/down arrow keys, so Apple's PDFKit handles those. And Preview also uses PDFKit, so it must work the same. Also it has been reported to me that Preview does the same in this respect. I also see no reason why any remote back/forward buttons would be related to up/down arrows.

Anwyway, as we don't handle these events, we also cannot fix them.

[yuggib]

I think I have isolated the issue, and it is not related to full screen and presentation mode. It appears to be a Skim only issue, so I think/hope it can be solvable. Whenever the view is set to single page mode, and not on the continuous mode, the behavior of up and down keys is inverted (in preview, it is not like that, and in single page mode the arrows behave as before, up goes back and down goes forward).

[Christiaan Hofman]

Yes, I know that the up/down key are inverted in 10.10. But again, we don't handle those events. Apple's PDFKit does. Therefore it should be Apple that should fix this. We cannot fix this, even if we wanted to, because Apple has made this private.

What I find really very, very strange is that Preview does not have this issue. Because it is also based on PDFKit. If they fix this in Preview, than they would decide this is wrong, so why wouldn't they fix it in the source in PDFKit? That makes absolutely no sense.

[James]

Hi Christiaan, I'd just like to add here that TeXShop did fix this very bug in their last update for their preview window (see here), so this is something that is fixable by the apps that use PDFKit. I'm not sure that Apple is going to fix this.

[Christiaan Hofman]

TeXShop has a horrible "fix". It fixes it by adding more bugs. For instance, it disables scrolling by arrows in some cases when that should be done. I have not been able to fix this in any reasonable way, without adding new scrolling bugs.

[aslanix]

I am here to say that I also just discovered this behavior, and also checked that Preview has the expected behavior. I hope this can be fixed in an update.

[Christiaan Hofman]

I've already found a workaround for the next release

[Jeremie]

This is wonderful news, because this bug has been driving me crazy since it was introduced - about a month ago. I kept thinking I was going crazy! (And curiously, this also affects the space bar, which moves pages in reverse order as well.)

[Marius Hofert]

Hi Christiaan, I also reported this undesirable behavior two days ago (without realizing that others have run into it before). You mentioned that you found a workaround for the next release. Since this is now half a year later, will the workaround be released soon?

[Christiaan Hofman]

Yes, there was a workaround. But that had its own problems. And the bug is really Apple's bug and therefore they are responsible to fix it. And Apple told me they fixed this in 10.10.3. So the workaround has been removed. This is apparently true for the arrow keys. But the page up/down keys still have the problem, apparently. I told Apple (though they have so far refused to confirm this to me.) Hopefully they will fully fix this in 10.10.4.

[Jeremie]

This bug does not just affect presentation mode, but also normal viewing of document (and affects not only arrows - which are now fixed -, but page keys, and space bar which are not).

I suspect this has to do with Apple's craze to invert up/down to be in line with touch devices.

Marcus: Christian is correct in saying that this should be fixed by Apple - because adding a hack to the application is just kicking the can down the road. But in the meantime, you can, remap your keyboard specifically for Skim using this flexible (and very stable) keyboard remapping tool:
https://pqrs.org/osx/karabiner/

Depending on what your issues or needs are, you can remap specific keys and only for Skim (and only for certain windows of Skim). For example, by adding the following setting definitions I am able to use the space bar correctly again:

<appdef>
  <appname>SKIM</appname>
  <equal>net.sourceforge.skim-app.skim</equal>
</appdef>

<item>
  <name>Fix Skim.app navigation (Mac OS X 10.10.3)</name>
  <identifier>private.skim_navfix</identifier>
  <only>SKIM</only>
  <uielementrole_only>AXTextArea</uielementrole_only>
  <autogen>
    __KeyToKey__
    KeyCode::SPACE,
    KeyCode::CURSOR_DOWN
  </autogen>
  <autogen>
    __KeyToKey__
    KeyCode::CURSOR_UP, ModifierFlag::FN,
    KeyCode::CURSOR_DOWN, ModifierFlag::FN
  </autogen>
  <autogen>
    __KeyToKey__
    KeyCode::CURSOR_DOWN, ModifierFlag::FN,
    KeyCode::CURSOR_UP, ModifierFlag::FN
  </autogen>
  <!-- and so on ... -->
</item>

This fixes the navigation mode and presentation mode - and the space bar and page up/down keys (without affecting the ability to enter annotations with the correct space bar). This is thanks to Karabiner's useful AXNotifier feature which allows to specify application and UI-specific remappings. I will shoot an email to Takayama (creator of Karabiner) to suggest he add this remapping so it can be used without modifying the private.xml file.

It might seem like a hack, but this absurd bug exactly requires a hack. And the fantastic thing is, it works!!

[Jeremie]

Just to confirm that Takayama has just added the setting to Karabiner, and it is now part of the latest beta (and the next release shouldn't be too far away):

https://github.com/tekezo/Karabiner/commit/f1ed48509be8fa9d90c88eb6f7a8ba72d792e82c

[Andrew Jaffe]

Please try to fix this!

I admit that I don't understand how this is an Apple bug -- I don't see it any other PDF-viewing apps! (I also appreciate that it can still be Apple's fault nonetheless, but it's not obvious.)

To be specific, does this include the bug in the PgUp/PgDn key-directions?

Does everyone using Skim see this?

[Christiaan Hofman]

It is an Apple bug because Apple's PDFKit handles these key events, our code is not involved. If you don't see it in other apps it's because they have workarounds for those bugs. But that is not the way to go, it should be fixed in the source. And moreover Apple has already partially admitted it is their bug (for the arrow keys).

[Jeremie]

As I suggested, download and install Karabiner, then select the "Fix Skim.app navigation" option, until Apple corrects the problem:
https://pqrs.org/osx/karabiner/

[Andrew Jaffe]

Thank you for reinstating the change.

However, it seems like only a partial fix -- it still doesn't work correctly in PDF->Single-Page mode...