Filament•3mo ago

Url not changing after some navigations in SPA mode

When navigating a few times, the url stops changing into the new route (stays on the old one), even though the actual page content does change. I've tested this in Chrome and Safari with a fresh Laravel 12 + Filament v4 install, see the attached video (i performed a clean install, added a custom page and enabled SPA mode). I've seen the same thing happen in one of my other apps running Filament v3. After waiting a few seconds and then navigating to another page, the url does change again. Chrome logs a warning when this happens, see the attached screenshot. I looked into this warning and found a Livewire PR https://github.com/livewire/livewire/pull/9278 which may be related, however that doesn't seem to have fixed this specific issue. I'm asking here because i'm unable to reproduce it in a Livewire application. Any guidance or solution would be helpful, or some direction on where to look to investigate this further. Thanks!

Solution:

I've created a view with the JS code and used Filament's render hooks to render it. navigation-fix.blade.php ``` <script> (() => {...

Jump to solution

40 Replies

RobinOP•3mo ago

Dennis Koch•3mo ago

You mentioned that error message: The browser thottles it, because you are changing too fast. Not sure what we should do about it or how we should help with that.

RobinOP•3mo ago

Yes i understand the error 😄 , it's just i've never seen that error on any other website

Dennis Koch•3mo ago

So you tested with a Livewire app that uses SPA and wire:navigate and clicked multiple times with the same speed? Maybe it's because the browser has to use more resources to render Filament compared to a simple Livewire page.

RobinOP•3mo ago

Yes Yea i think so too, i've only tested with an almost empty livewire app

RobinOP•3mo ago

I see that window.history.replaceState gets called many times on each page load. I've added a console.log at the same line where replaceState gets called, the result is the screenshot. Here i'm loading the dashboard once.

RobinOP•3mo ago

It's the same line mentioned in https://github.com/livewire/livewire/pull/9278. They only added a try/catch block I have no idea why it gets called so many times, do you?

RobinOP•2mo ago

I decided to dive into this again today; turns out the issue is caused by Livewire's #[Url] attribute. I will bring this up with them and keep this thread updated. In case anyone's interested, here's a basic Livewire app showing the same issue (just click settings/welcome a couple of times); https://github.com/robinvda/livewire-navigation-throttle-issue

GitHub

GitHub - robinvda/livewire-navigation-throttle-issue

Contribute to robinvda/livewire-navigation-throttle-issue development by creating an account on GitHub.

drabew•2mo ago

https://github.com/livewire/livewire/discussions/5923 hotfix from Capevace seems to work, but problem exists for many years in Livewire and it's still unresolved.

GitHub

Fatal JS error: SecurityError: Attempt to use history.replaceState(...

I am running a Filament beta app on a staging environment. Filament V3 uses the wire:navigation feature. If I quickly click through 7 pages (e.g. via the sidebar), then the following error will hap...

RobinOP•2mo ago

Hmm I'm curious why there are not more reports about this. The Filament demo also has this issue https://demo.filamentphp.com/

David | Fortune Validator•2mo ago

I can confirm I’m having the same issue. Weirdly I’m noticing it far more on v4 but that could be coincidence. Did you find any fixes or any sort of bandaid fix. What I don’t understand though is I’m barely using the URL attribute and I’ve notice the error on pages that don’t have it at all. For clarity I’m not using SPA mode either

RobinOP•2mo ago

I'm currently using a workaround which is to "throttle" calls to the replaceState function, it's posted here https://github.com/livewire/livewire/discussions/5923#discussioncomment-9202549

GitHub

Fatal JS error: SecurityError: Attempt to use history.replaceState(...

RobinOP•2mo ago

Filament is using it quite a lot internally

David | Fortune Validator•2mo ago

That would explain why I couldn’t find the issue in my code. Do you think there is anything else we can do? If we have a lot of main navigation links I suppose this may add to the issue ? Can we opt to not have wire:navigate anywhere do you know ? I’ve been trying to fix this for days now https://discord.com/channels/883083792112300104/1407407821770723449 cross linking my help post. It didn’t get anywhere

RobinOP•2mo ago

I've also spent a lot of time trying to fix it, but the issue seems rooted to deeply into Livewire for me to understand.. The workaround works, even though it's not a nice fix. I've updated the code mentioned in that post a bit, i can post it here next week.

David | Fortune Validator•2mo ago

Yeah if you wouldn’t mind posting the code that worked for you I would greatly appreciate it. Thankyou. Have a good weekend

Solution

Robin•2mo ago

I've created a view with the JS code and used Filament's render hooks to render it. navigation-fix.blade.php

<script>
    (() => {
        const original = window.history.replaceState;
        let timer = Date.now();

        let timeout = null;
        let lastArgs = null;

        window.history.replaceState = function (...args) {
            const time = Date.now();

            if (time - timer < 100) {
                lastArgs = args;

                if (timeout) {
                    clearTimeout(timeout);
                }

                timeout = setTimeout(() => {
                    original.apply(this, lastArgs);

                    timeout = null;
                    lastArgs = null;
                }, 100);

                return;
            }

            timer = time;

            original.apply(this, args);
        }
    })();
</script>

<script>
    (() => {
        const original = window.history.replaceState;
        let timer = Date.now();

        let timeout = null;
        let lastArgs = null;

        window.history.replaceState = function (...args) {
            const time = Date.now();

            if (time - timer < 100) {
                lastArgs = args;

                if (timeout) {
                    clearTimeout(timeout);
                }

                timeout = setTimeout(() => {
                    original.apply(this, lastArgs);

                    timeout = null;
                    lastArgs = null;
                }, 100);

                return;
            }

            timer = time;

            original.apply(this, args);
        }
    })();
</script>

In a service provider;

        FilamentView::registerRenderHook(
            PanelsRenderHook::BODY_END,
            fn (): View => view('core::navigation-fix'),
        );

        FilamentView::registerRenderHook(
            PanelsRenderHook::BODY_END,
            fn (): View => view('core::navigation-fix'),
        );

David | Fortune Validator•2mo ago

Thank you for this. I appreicate the code and the instructions. I'll try it out. Have you noticed any adverse effects?

RobinOP•2mo ago

So far no, only that it takes about 100ms for the url to change in the address bar. But i have only run it for one day in my dev environment, not yet in production

David | Fortune Validator•2mo ago

Roger that thanks.

RobinOP•2mo ago

Happy to help 🙂 if there's any update I'll post here, but i doubt it

David | Fortune Validator•2mo ago

Thanks bud. Likewise So I just spun up my filament v4 repo on a live staging site and perhaps because it’s slower than local using herd but I don’t have the issue yet ( few mins of testing ) p.s I hadn’t yet tried your code.

RobinOP•2mo ago

Interesting.. I suppose the slower the environment, the less chance there is of the error appearing

David | Fortune Validator•3w ago

So I’m still getting it a fair amount of production. How’s it going your end?

RobinOP•3w ago

There's still no official response on the issue. The workaround is working ok for me, at least for now.

David | Fortune Validator•3w ago

No lost data or anything? I’ll be honest I don’t understand the fix but so long as there is no chance that actions are dropped off such as saving data then that would be okay

RobinOP•3w ago

Calls to history.replaceState are debounced, which means if that function is called let's say 50 times within 100ms, it is only executed once (the final call).

David | Fortune Validator•3w ago

Okay so an action such as a Save or a redirect should be fine ? Thanks Robin

RobinOP•3w ago

Yes that should be fine, i haven't had any issues so far

David | Fortune Validator•3w ago

Makes you wonder why this is not an official fix though eh

RobinOP•3w ago

It's a bit of a duct tape solution, but it works. I'm just surprised that there's so little response or follow-up on this by the Filament or Livewire team. Surely we can't be the only ones experiencing this issue 😅

David | Fortune Validator•3w ago

Haha yeah I know what you mean. I think maybe with v4 rendering faster the issue has arisen more. My app is a crm system so you dart from page to page which means I’m getting hit by it frequently

Dennis Koch•2w ago

Sorry, I overlooked this one. I thought this is just from navigation, but didn't realise a single page visit calls replaceHistory that often. I think we need to investigate this further.

Dennis Koch•2w ago

I opened an issue for this: https://github.com/filamentphp/filament/issues/17880

GitHub

[4.x] Browsers throttle navigation because of multiple `history.rep...

Package filament/filament Package Version v4.0.18 Laravel Version v12.30.1 Livewire Version v3.6.4 PHP Version PHP 8.4.12 Problem description Just switching pages can result in the browser throttli...

David | Fortune Validator•2w ago

Thanks Denis. It would be wonderful to be fixed If it helps the issue presents itself far more often in v4 compared to v3

Dennis Koch•2w ago

This issue seems to be a long-existing Livewire issue. Here's my summary on it. https://github.com/filamentphp/filament/issues/17880#issuecomment-3316041960

GitHub

[4.x] Browsers throttle navigation because of multiple `history.rep...

Dennis Koch•2w ago

I marked the workaround as the solution, because it's a temporary fix and there's not better solution right now.

David | Fortune Validator•2w ago

Thank you. Can you see any downsides to using the workaround fix ? Any risk to lost data essentially on create or edit pages for example At the moment I have examples of using the create page and the db up updated but I don’t get redirected ( the redirect is held off due to this throttle ). Causing the user to save twice So I’d like to stop that. Just nervous about a bandaid fix on production.

Dennis Koch•2w ago

Hm, not sure. I think the only issue could be, when user hit save and quickly switch to another page. But if they wait for the success message, it should be goot.

RobinOP•2w ago

Thank you for the follow-up Dennis, let's hope this gets the attention of the Livewire devs 🙂

Gaming

Programming

Url not changing after some navigations in SPA mode

Did you find this page helpful?