fix(sheet): changing the way sheet footers work during dragging

[ShaneK]

Issue number: resolves several (listed at the bottom) + internal

---

What is the current behavior?

Currently, when expand to scroll is disabled in a sheet modal, we duplicate the footer on drag and show a cloned version in the shadow DOM instead of the original. This causes many issues (described in the Other Information section), especially because often times the cloned version of the footer would stick around instead of the original version, which made any event listeners in the footer (and styling) broken by default instead of only while dragging.

What is the new behavior?

We are now following method 2 of the design doc, with minor deviation.

Now we try to eliminate the shaky behavior in the footer by setting the footer to be absolutely positioned on the page and adding padding to the bottom of the modal while dragging is happening to offset the missing footer content. We are additionally performing some extra logic to swap back when the modal is dragged below the height of the footer so that it collapses correctly visually.

Note this is a minor variation in method two from the design doc because I moved the footer to the body instead of to the parent modal. This is because the parent modal will prevent anything not in its ion-page from displaying, but it seems to work fine. As a side-effect of this, I had to add an extra class and support for that class in a few areas so we could identify footers that belonged to modals while they were moving and apply applicable classes.

Additionally with this change I was able to remove all of the extra code in the leave/enter animations because we no longer need to worry about managing a clone of an element there. This allows me to contain all code relating to behavior of the footer to sheet.ts.

Does this introduce a breaking change?

• Yes
• No

Other information

This refactor in how the footer combats shakiness should resolve many issues caused by that, including the following:

• this change no longer has the footer being swapped out, effectively breaking event listeners, which fixes bug: sheet modal. EventListeners don't work on ion-footer when expandToScroll is false #30315
• this change no longer has the footer being duplicated at all, which fixes bug: sheet modal. An input field or text area element in an ion footer in a sheet modal is duplicated on first open & resize animations #30341
• this change no longer has the footer (sometimes) being moved to the shadow DOM, which fixes bug: sheet modal. Cloned ion-footer doesn't apply stylesheets #30312

Current dev build: 8.5.8-dev.11748450896.16232653

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ionic-framework	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 28, 2025 4:38pm

[kumibrr]

@ShaneK Thanks for the heads-up!

I had tried a similar approach but ran into issues on larger viewports:

Screen.Recording.2025-05-28.at.09.39.43.mov

While investigating the bug, I attempted to address it by setting the modal’s width as the max-width of the footer and using transform: translateX. However, I struggled to get the right transform value.

Additionally, we must apply padding to the footer’s last toolbar to account for the bottom safe area.

[ShaneK]

Hey, I greatly appreciate that, can't believe I didn't catch it! Let me do some more investigating today and I'll see what I can come up with. Thank you!

[ShaneK]

Hey @kumibrr! I've attempted to address this by pinning the constraints of the footer while it's being dragged. Can you please try again and see if you can identify any issues with this approach?

I know you just used the test page for the flaw you found before, but if you want to try on a different project, there's a new dev build: 8.5.8-dev.11748450896.16232653

[kumibrr]

@ShaneK Yeah, I've noticed that the jittering is back on Safari and lower-end devices using chrome. This is caused because somehow the footer element is positioned relative to the parent. To better debug it, turn on CPU throttling in your browser dev tools as Chrome's swiftness hides the issue.

[ShaneK]

@ShaneK Yeah, I've noticed that the jittering is back on Safari and lower-end devices using chrome. This is caused because somehow the footer element is positioned relative to the parent. To better debug it, turn on CPU throttling in your browser dev tools as Chrome's swiftness hides the issue.

Is this after you drag and then let go and it's still animating? That's a known issue and it occurs with the current implementation too

[kumibrr]

@ShaneK Exactly.

I've tried with the current implementation and it doesn't happen. The cloned footer was created to solve that exact issue. Is there any instance where it does happen I missed?

[ShaneK]

@ShaneK Exactly.

I've tried with the current implementation and it doesn't happen. The cloned footer was created to solve that exact issue. Is there any instance where it does happen I missed?

When you're dragging and you let go and it's still animating it swaps back, though I did notice sometimes it doesn't swap back correctly so it may not always happen. Does it jitter with this implementation when you're holding it too or only after you let go? It doesn't make sense that this could be bound to the location of the parent since it's moved to the body.