bug: interactions not allowed on app until page transition animation has completed

[aeharding]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Ionic Framework Version

v7.x

Current Behavior

You cannot scroll down a page during a page transition

Expected Behavior

Page should accept interactions before page transition has completed

Steps to Reproduce

1. Tap into a page or swipe back to trigger the page transition animation
2. Immediately try to scroll down before the page has finished transitioning

Code Reproduction URL

No response

Ionic Info

Ionic:

   Ionic CLI : 7.1.1

Utility:

   cordova-res : not installed globally
   native-run  : not installed globally

System:

   NodeJS : v18.15.0
   npm    : 9.5.0
   OS     : macOS Unknown

Additional Information

This bug is made a bit more serious by https://bugs.webkit.org/show_bug.cgi?id=222654

You can experience this bug in production at https://wefwef.app

Please see a demo video (with narration) explaining the video in real time:

IMG_2717.mp4

And here's a video (without narration) demonstrating how long it takes for pointer-events: none to be removed from both pages by slowing down the animation to 10% real time:

Kapture.2023-07-05.at.12.13.50.mp4

Related bug: aeharding/voyager#18

[liamdebeasi]

Thanks for the report. Can you please clarify what the expected behavior is here? Scrolling should be blocked until the transition is complete. This behavior aligns with how native iOS apps behave.

[aeharding]

Hi there! Expected behavior is two things:

1. Scroll gestures before the animation is completed shouldn't latch to the document root until you wait a few seconds without interaction (see my video demonstration). iOS native apps like Settings this does not happen. I believe that is due to https://bugs.webkit.org/show_bug.cgi?id=222654, however, so that is not the focus of this bug report. (However, it does make this bug report much more noticeable.)
2. Some native iOS apps, like Apollo for Reddit, allow scrolling before the animation is complete. At very least, it would be nice if this was configurable - or at least allow a slot so I can potentially override this behavior with CSS. (Because pointer-events: none is set in shadow DOM without slot, I cannot potentially override.)

I speculate that fixing 2) would "fix" 1) because there would always be an ion-page scrollable target, and scroll gestures wouldn't get latched to the document (above webkit bug).

I've received quite a bit of feedback over the past week from wefwef users about how the current behavior is irritating to wait for the animation to complete, especially when swiping back and forth a lot.

I hope that helps!! :)

[liamdebeasi]

Scroll gestures before the animation is completed shouldn't latch to the document root until you wait a few seconds without interaction (see my video demonstration). iOS native apps like Settings this does not happen. I believe that is due to https://bugs.webkit.org/show_bug.cgi?id=222654, however, so that is not the focus of this bug report. (However, it does make this bug report much more noticeable.)

Yeah this is an unfortunate bug. In my experience posting comments on the WebKit thread about how this bug impacts your application can help the WebKit team prioritize the fix appropriately. It sounds like getting https://bugs.webkit.org/show_bug.cgi?id=214781 fixed (a related issue) would significantly improve the UX here.

Some native iOS apps, like Apollo for Reddit, allow scrolling before the animation is complete. At very least, it would be nice if this was configurable - or at least allow a slot so I can potentially override this behavior with CSS. (Because pointer-events: none is set in shadow DOM without slot, I cannot potentially override.)

I'm not sure I understand the use case for this. What's the benefit of being able to scroll a partially obscured page? The page elements are not set in the Shadow DOM. Your video in #27748 (comment) at timestamp 0:10 shows the page content in the light DOM. You could override this, but it may cause unexpected behaviors.

[aeharding]

I'm not sure I understand the use case for this. What's the benefit of being able to scroll a partially obscured page?

Imagine you're scrolling a feed, you tap into something, swipe back to the feed, and then want to keep scrolling.

Once the page starts transitioning you start scrolling down, because you know the item you just read is what the feed is focused on.

That's the use case - I can make another video if it would help :)

The page elements are not set in the Shadow DOM. Your video in #27748 (comment) at timestamp 0:10 shows the page content in the light DOM. You could override this, but it may cause unexpected behaviors.

I've actually just tried this, thanks for the suggestion! - but the problem is that it only works in a forward direction, because in that case the page transitioning to has a higher z-index.

Code:

.ion-page ion-content {
  pointer-events: all !important;
}

(It also has issues where sometimes the scroll target is captured by the leaving ion-page - which could be fixed by an ion-page-leaving class.

I'm just trying to think of the easiest way to solve this... Maybe if there was a .ion-page-leaving class? Then I could override pointer events only if not leaving. (The leaving page is the one I never want to scroll.)

Here's the code that I'd love if it were possible:

.ion-page:not(.ion-page-leaving) ion-content {
  pointer-events: all !important;
}

Unfortunately I can't test out if this would work easily since it would require modifying ionic.

[liamdebeasi]

Imagine you're scrolling a feed, you tap into something, swipe back to the feed, and then want to keep scrolling.
Once the page starts transitioning you start scrolling down, because you know the item you just read is what the feed is focused on.

I don't understand why this is a desired behavior. Being able to interact with a page mid-transition would also mean you could potentially navigate to another page while a navigation is already in progress. At that point it's not clear what should happen. (Should it be ignored? Should the new transition interrupt the old transition? Should the new transition only run when the old transition finishes?). The requested behavior also does not align with how native mobile apps typically work, so I'm not sure this feature would be a good fit for Ionic.

[aeharding]

The requested behavior also does not align with how native mobile apps typically work, so I'm not sure this feature would be a good fit for Ionic.

I totally get that. However, this is something I keep hearing from users. To be fair, it might be mainly due to the safari scroll latching bug.

Would it help if I did some more research to find native apps that behave this way?

Thanks for discussing this with me!

[liamdebeasi]

Perhaps I am misunderstanding what the root issue is. In #27748 (comment) you provided a video that demonstrated how long it takes for pointer-events: none to be removed from both pages after the transition ends. However, the original post also requests that pointer-events: none be removed in general.

Is the problem here that pointer-events: none takes too long to be removed after the transition, and therefore you are requesting that CSS be removed in general?

[ionitron-bot]

Thanks for the issue! This issue is being closed due to the lack of a reply. If this is still an issue with the latest version of Ionic, please create a new issue and ensure the template is fully filled out.

Thank you for using Ionic!