Link handling different in iOS standalone mode

[ethanmick]

Hey all, first, I love react-aria. Fantastic library and great job!

This is really obscure issue, but also something I was hoping react-aria would smooth over.

In iOS (15.6) how iOS is handling pressing down on a link and then sliding the finger off is triggering different behavior. In regular browsing mode, Safari correctly cancels the press and does not navigate. When pressed and finger slid off in standalone mode, the link is still triggered and the page changes. This only happens in iOS PWA standalone mode:

// This is needed and you need to add it to your home screen as a web app!
<meta name="apple-mobile-web-app-capable" content="yes" />

This only becomes more apparent when I add:

touchAction: "none",
userSelect: "none",
"-webkit-touch-callout": "none",
"-webkit-user-drag": "none"

as CSS to make the links function much closer to iOS buttons (building an iOS standalone webapp, I want it as close as possible to a native app). It still happens without it though, just harder to detect. I was hoping that React-Aria would be able to correctly cancel the navigation when the user slides their finger off the link.

Links

• GitHub Repo
• Vercel Link
• Code Sandbox/Preview

Repro

1. Go to https://react-aria-ios-standalone-cancel.vercel.app/ on iOS
2. Click the link and move as the picture above describes. Note the page does not navigate.
3. Click "Share"
4. Click Add to Home Screen
5. Open the new web app
6. Perform the action again
7. The page navigates instead of canceling the link touch

Workaround

The odd thing is that with all my testing, I've been able to get a workaround with react-aria. The onPress function is correctly identifying when a press ends on the link or has moved off. So I can use that to initiate a route change with the Next router. You can see me play around with that here. I'd much rather not need to do this, since I want correct links for screen readers and accessibility and would only use the client side navigation for standalone mode.

[LFDanLu]

Thinking out loud, we would need to preventDefault on the click event (or something similar) in usePress in order to stop the anchor navigation from happening but only if the touchup event is no longer intersecting with the original anchor element. Unfortunately it seems like the relatedTarget of the click event that happens in iOS PWA standalone mode won't give us the actual coordinates that the user lifted their finger so we'd have to get that from pointer up or something. In other browsers, onClick doesn't occur if your click/press is released off the original target so we may not need to do any extra conditionals to limit the above code to the iOS PWA standalone mode only (would need some thorough testing to make sure though). Maybe some other way to go about this?

I'm personally a bit wary of doing such a workaround due to all the potential unintended side effects, ideally this would be fixed as a browser bug IMO or if you could use onPress instead since that handles hit detection as you've noted in your "Workaround" section.

since I want correct links for screen readers and accessibility and would only use the client side navigation for standalone mode

What exactly did you mean by the above in regards to using onPress?

[ethanmick]

Hi and thanks for your response! I echoed your thinking when working through the problem where the library would need to correctly get the coordinates from the touch up action and map that back to see if the user was actually on the link. What annoys me is that this is working in other ways, the onPressEnd and onPressStart correctly trigger with the finger sliding on and off. Only the final lift of the finger exhibits different behavior.

since I want correct links for screen readers and accessibility and would only use the client side navigation for standalone mode.

Naively, I could just turn all my anchor tags into:

<a onPress={ () => router.push('/new-page')} />

And then they would all work correctly in standalone mode. But when I do that they lose their href attribute, so the links appear to have no link and things like mousing over to reveal the link won't work. So my code becomes a little gnarlier like:

const Link = ({href}) => {
  const ariaProps =
    typeof window !== 'undefined' && (window.navigator as any).standalone
      ? {
          onPress: () => {
            router.push(href)
          }
        }
      : {}
  const props =
    typeof window !== 'undefined' && (window.navigator as any).standalone
      ? {}
      : {
          href
        }

  const router = useRouter()
  const ref = useRef(null)
  const { linkProps } = useLink(ariaProps, ref)
  return (
    <a {...(linkProps as any)} {...props} ref={ref}>
      On Press Framer Aria Next Link 
   </a>
  )
}

It's not the end of the world. I was hoping to avoid it, or at least bring it to the attention here for if someone else runs into this problem. I can file a bug with Apple and see if they have a response and relay that back here too :)