You pair the pedal, the light goes solid, the phone lists it as connected. You open your charts in Safari, put your foot on it, and the page sits there. You press it again, harder, the way everyone does. Then you tab over to a news article, press it, and the article scrolls perfectly.
Here is what is happening.
A page-turner is a keyboard
Every Bluetooth page-turner sold for musicians presents itself to the phone as a HID keyboard. That is the whole of the device. It has one or two switches, and each switch sends a keystroke — usually Page Down and Page Up, or Down arrow and Up arrow, with a mode button to pick which pair. Some models add space or a letter key. There is no pedal protocol and no app to install; it’s a keyboard with two enormous keys.
That’s where the trouble starts, because keystrokes on iOS travel further than you’d expect before a web page hears them.
Where the keystroke stops
On iOS, the keystroke reaches Safari and goes no further. The page’s JavaScript is never told a key was pressed. This is a long-standing WebKit behaviour, not a bug in any particular site, and it holds for every mode the pedal offers.
It’s easy to verify and worth doing once. Open the same page in a desktop browser with a keyboard attached and every press of the pedal fires a keydown event the page can see. Open it on an iPhone or iPad and nothing arrives, in page mode or arrow mode.
The reason it feels intermittent — working on some pages, dead on others — is that WebKit still scrolls the page itself. On a long article, the scroll you see is Safari doing its own thing with the key, and the page was never involved. So the pedal looks like it works right up until you land on a page that needs to handle the key in code: a chart that scrolls by a measured amount, a set that steps to the next song, anything that isn’t a document being dragged upward.
Switching browsers doesn’t help: Chrome and Firefox on the iPhone are WebKit with a different icon, and inherit the same behaviour. Nor is there anything for a website to ask for — no permission prompt, no setting buried in Safari, no API for requesting raw key input. No website can work around this, and any site claiming to has quietly meant “we scroll like a normal document”.
Checking the pedal itself
Two minutes, and you’ll know where you stand. Pair the pedal with a laptop, open any text editor, and press it: the cursor jumps a page, or moves a line, depending on the mode. That’s the pedal sending exactly what it is supposed to send, and everything past that point is a software boundary. While you’re there, note which keys each mode sends and how to switch between them — usually a button held for three seconds.
What a native app does instead
A native app gets the keystroke before any of this comes up, because it isn’t asking a web page for anything.
On iOS the mechanism is the UIKit responder chain. A view controller declares the key commands it wants — Page Up, Page Down, Up arrow, Down arrow — and UIKit delivers the press to it directly. That sits above the web view entirely, so what WKWebView does or doesn’t pass through to JavaScript stops being relevant. Chordisplay’s iOS app declares those four and scrolls the chart itself.
Android reaches the same place by a different route. Pedals are HID keyboards there too, and key events travel down through the view hierarchy, where the focused web view claims the arrows and the page keys for its own scrolling. An activity that waits its turn never sees a single one of them. Taking them ahead of the hierarchy, in dispatchKeyEvent, does work — so that’s where the Android app handles them.
Both apps then move the chart by the same amounts: the page keys travel 0.9 of a screen, the arrows nudge 0.125 of one, both scrolling smoothly rather than jumping. A full screen sounds tidier and isn’t — the line you were reading ends up just off the top, and you lose your place at the one moment you can’t afford to.
The parts only real hardware teaches
Arrow mode looked fine in the iOS Simulator with a Mac keyboard forwarded through it, and did nothing at all on a real device with a real pedal until the arrows were handled explicitly. Holding the pedal down is another: key repeat is right for the small nudge, but repeating a full-screen jump at the repeat rate throws the chart off the screen in about a second, so the Android app repeats the fine scroll and ignores repeats on the page keys. And an arrow pressed while a search box has focus belongs to the text cursor rather than the page, so those get handed straight back.
If you’re shopping for a pedal, none of this narrows the field much: check that it sends the page keys or the arrows, and that you can switch between them. What decides whether it works is on the other end — whether what you’re reading from is a native app or a browser tab.