Netnewswire: macOS Accessibility Keyboard: up and down arrows don't scroll detail pane

[blakewatson]

Scrolling with up and down arrows is preferable to the space bar to me because it allows small increments of scrolling instead of the whole page. I find it jarring to read all the way down to the edge of a page. And I tend to lose my place when the whole thing scrolls. I suppose it's inefficient, but I appreciate having more control over the scroll. Not to mention the ability to scroll up to go back to something.

It doesn't seem like up and down is being used for anything else while focused on the detail pane, so I thought I would ask. 😄

(If the up and down arrows are supposed to be scrolling up and down... then I guess this is a bug report instead of a feature request).

[vincode-io]

Up and down arrows do work. You just need to make sure that the UI focus is on the article view. You can do that by clicking on the body of the article or using the right arrow key to move focus from the timeline to the article.

[blakewatson]

You know what... I should have mentioned I'm using the macOS Accessibility Keyboard. Important detail, I know. 😬

[brentsimmons]

I should learn about that. We’ll take a look.

[blakewatson]

Subscriptions and headlines work fine. Also, it seems that the focus gets stuck in the detail view—the left arrow doesn't return to the headlines. It basically does nothing.

[blakewatson]

Here's a demo of the behavior:

https://www.youtube.com/watch?v=5WCeDlQa1gA

[brentsimmons]

That’s super-helpful. Thanks, Blake.

I have no idea off the top of my head why this isn’t working correctly, but we’ll look into it.

[blakewatson]

I had a suspicion that it wasn't the Accessibility Keyboard. So I got someone to help me test the physical keyboard (MacBook Pro). Same behavior. Except we discovered that holding down the down arrow key eventually scrolled the pane erratically (same with both the physical and onscreen keyboards). Almost like there’s an invisible text cursor.

[blakewatson]

Okay yeah. It's _exactly_ like there's an invisible text cursor. I set the focus on the first line of an article and counted how many times I needed to press down to get it to scroll. It was the same as the number of lines on the page.

[blakewatson]

Actually, if I hold shift to create a selection, then I can see the cursor move down the page line by line.

[Wevah]

In setting some breakpoints, it seems like override func keyDown(with event: NSEvent) is never actually called on our WKWebView subclass. 🤔

Edit: It's not called if the web view can be scrolled. I was hoping it could just be overridden there, but no dice.

[vincode-io]

I'm at a loss to prevent this behavior. I think it is the intended behavior of WKWebView when the Accessibility Keyboard is active and the WKWebView is first responder. My theory is that Apple has done this so that web text is selectable using the keyboard when using the Accessibility Keyboard. I'm not sure why Safari is different though.

I tested Vienna which also uses a web view. It has the same behavior.

[blakewatson]

Yeah whatever this behavior is continues to plague me. But you’re right, it happens in other apps too. I wish that Space or Page Down (the only other way I know to scroll by keyboard) would go 1/2 or 3/4 of a page instead of a literal whole page. I don’t understand how going a whole page is practical—as if I want to read down to the very last line of a page before scrolling.

Not criticizing NetNewsWire, I just mean standard UI behavior in general.

The Accessibility Keyboard has been kind of glitchy in Catalina so I’m hoping it has improved in Big Sur. I’ll report back here for sure.

[vincode-io]

I'm sorry this is happening to you. If I knew of some way to fix it, I would.