Larajax Turbo view transition direction attribute removed before animation runs

Need Help
#1

Hi @daftspunk,

I’m trying to use Larajax Turbo view transitions with directional animations as documented here:

The default view transition crossfade works fine when I add:

<meta name="turbo-visit-control" content="enable" />
<meta name="turbo-view-transition" content="same-origin" />

However, the directional animation CSS from the docs does not seem to take effect. I only get the default browser crossfade.

I checked the runtime behavior and data-turbo-visit-direction="forward" is briefly added to the <html> element during page:visit. At that moment the CSS selectors match correctly. But the attribute is removed again around page:load / page:loaded, before the visible View Transition animation is actually running. When the animation is active, the computed animation is back to the browser default -ua-view-transition-fade-in/out.

So it looks like the direction attribute may be removed too early for the ::view-transition-old(root) / ::view-transition-new(root) rules to apply.

Is this expected behavior, or could this be a timing issue/bug in Larajax Turbo view transitions?

Thanks!

#2

I also noticed a related issue with browser back/forward navigation and scroll restoration.

Example:

  1. Open page A and scroll near the bottom.
  2. Navigate to page B.
  3. Use the browser Back button to return to page A.

Before the view transition starts, the currently visible page B is scrolled to the restored scroll position of page A. Then the crossfade begins. So the outgoing page visibly jumps first and only then fades out.

Setting history.scrollRestoration = "manual" on the frontend seems to prevent the browser from applying the target history entry’s scroll position too early.

This makes me wonder if Larajax Turbo should set history.scrollRestoration = "manual" internally when it manages its own restoration data, especially when view transitions are enabled. Otherwise browser-native scroll restoration and Larajax’s own scroll restoration appear to interfere with each other.

#3

Hey @Amin,

Thanks for the detailed report. Both issues have been fixed in Larajax v2.2.2:

  1. data-turbo-visit-direction now stays on the <html> element until the view transition animation fully completes, so your directional CSS selectors should work as expected.

  2. The framework now sets history.scrollRestoration to manual while active, preventing the browser from jumping the page before the view transition captures the old state.

Could you give v2.2.2 a try and let us know if that resolves both issues on your end?

1 Like
#4

Thanks for the quick turnaround on scroll restoration — that behaviour is fixed on my side now (history.scrollRestoration no longer fights Turbo during back/forward).

View-transition direction is still wrong for me: data-turbo-visit-direction is still removed almost immediately (around page:load / page:loaded), so when the View Transition actually runs, the attribute is already gone and only the default crossfade (::view-transition-* UA fade) applies — my directional rules never stick.

So from here it still looks like a timing/lifecycle issue with when the direction attribute is cleared, unless I’m missing something (e.g. a required meta flag, or needing a specific build/asset refresh).

1 Like
#5

Hi @daftspunk,

After updating to 4.4.20, I noticed that data-turbo-visit-direction now persists longer, which is great.
However, in my case it only ever has the value "back" — I never see "forward".

#6

Oh, I see. I’ve added a fix for this.

Could you try including this file manually to see if it helps:

If this works we will publish it