Input value from browser's snapshot overwrites Alpine's state during tab restore

[Jipok]

Steps to reproduce

1. Open two browser tabs with this code:

<div x-data="{ testInput3 : $persist('default value') }">
    <input x-model="testInput3" type="text">
    <p>Value: <span x-text="testInput3"></span></p>
</div>

2. In Tab 1: Change input value to "value 1" and suspend/discard the tab
3. In Tab 2: Change input value to "value 2" (this updates localStorage)
4. Restore Tab 1

Expected behavior

When Tab 1 is restored, it should show "value 2" (the current value from localStorage that was set in Tab 2)

Firefox behavior

• Input shows "value 1" (from tab snapshot)
• Span shows "value 1"

Chromium behavior

• Input shows "value 1" (from tab snapshot)
• Span shows "value 2" (correct value from localStorage)

This suggests that Firefox triggers Alpine's reactivity system when browser restores input value, while Chrome doesn't propagate this restored value to Alpine's state. Both bad.

This may seem like a small problem. But I used it not with $persist but with my own $persist magic. I have an "application" that assumes offline operation and sending changes to the server when the connection is restored. In fact, I don't even have localStorage used, it is assumed that the user simply does not close the tab. I discovered this problem when I restored an old tab with an outdated value in Firefox and alpine assumed that the user changed the input and sent a "new" value to the server.

If you use logging in Alpine.Effect at alpine:init, you can see that first triggered with value 2, and then immediately with 1.

[SimoTod]

I agree that the inconsistence between firefox and chrome is weird but the behaviour you see in firefox is what I would expect.
Persist only reads the value when the component is initialised. After that point it only writes the values back to the persistent storage.
Changing the value from outside the component does not refresh the component, you can easily see it by using 2 different components on the same page that "share" the same persisted value: https://codepen.io/SimoTod/pen/JojKRyo

[ekwoka]

You could make your own interceptor that syncs the persistance.

I'd say in the Firefox example, it hasn't really discarded the state. It's maintaining it.

Chrome actually discarded the Js context and rebuilt it while forcefully maintaining dirty input values.

[Jipok]

Chrome actually discarded the Js context and rebuilt it while forcefully maintaining dirty input values.

Firefox did the same. Restarted all the js, alpine:init and so on. I added more logging:

document.addEventListener("DOMContentLoaded", () => {
    const input = document.querySelector('input');
    console.log(`DOMContentLoaded: ${input.value}`);
 
    for (let i = 0; i <= 100; i++) {
      setTimeout(() => {
        console.log(`Value at ${i} ms: ${input.value}`);
      }, i);
    }
  });

document.addEventListener('alpine:initialized', () => {
    const input = document.querySelector('input');
    console.log("alpine:initialized: " + input.value)
});

document.addEventListener('alpine:init', () => {
    const input = document.querySelector('input');
    console.log("alpine:init: "+ input.value)

    let sync = (div, todoWTFValue) => {
        return Alpine.interceptor((defaultValue, getter, setter, path, key) => {
           Alpine.effect(() => {
                console.log("Alpine.Effect: " + getter())
    . . .
    Object.defineProperty(Alpine, '$sync', { get: () => sync() });
    Alpine.magic('sync', sync);
});

Chromium:

alpine:init:
Alpine.Effect: value2
alpine:initialized: value2
DOMContentLoaded: value2
Value at 0 ms: value1
Value at 1 ms: value1
Value at 2 ms: value1
Value at 3 ms: value1
Value at 4 ms: value1
Value at 5 ms: value1
WebSocket connected
Value at 6 ms: value1
Value at 7 ms: value1
...

Firefox:

alpine:init: 
Alpine.Effect:  value2 
alpine:initialized: value2 
DOMContentLoaded: value2 
Value at 0 ms: value2 
Value at 1 ms: value2 
Value at 2 ms: value2 
Value at 3 ms: value2 
Value at 4 ms: value2 
Value at 5 ms: value2 
Value at 6 ms: value2 
Value at 7 ms: value2 
Value at 8 ms: value2 
Value at 9 ms: value2 
Value at 10 ms: value2 
Alpine.Effect: value1 
WebSocket connected 
Value at 11 ms: value1 
Value at 12 ms: value1 
...

The difference in connection time seems to me to be because Firefox is my main browser with a bunch of tabs and add-ons. Chromium is empty and clean.
The most interesting thing here is that chromium restored the value to the moment before the zero timer but after DOMContentLoaded. And either Alpine didn't see it because it hadn't finished binding yet (I don't know how it works internally), or the browser didn't even send the event.

UPD: I tested:

document.addEventListener('alpine:initialized', () => {
    const input = document.querySelector('input');
    input.value = "ABOBA"

The value is still replaced by the browser

[Jipok]

But both behaviors are undesirable. The developer sets the values ​​he needs at the time of initialization. And then the browser just comes and changes everything.

[ekwoka]

It's likely part of how the browser manages forms so that users don't lose form values they have entered before leaving the page.

With that in mind, I am not sure it's appropriate for Alpine to attempt to force a behavior on the browsers, and it's up to the browser vendors to identify what would be an expected behavior for something like this.

I believe they would say the inputs should continue to show the edits made by the user before leaving, even if the site changes the value on initialization.

Which is likely what both are attempting to do, but with different points at which they do it.

Does navigating away and then back yield the same result?

🤔

I'm not saying you're wrong in your expectations, just discussing what seems like it would make sense in the grander scheme of things, not strictly your specific scenario...

Not sure if Alpine could/should try to also identify that the browser has "reset" the value and pull that in as well or not...probably?

Which way do you think it should go?

That the Dom reflects the $persist value?

Or that the Alpine state reflects the preserved form inputs?

[Jipok]

I think this is just another bug of bloated overcomplicated browsers. Such an event should be intercepted and controlled. Any attempt to fix this from Alpine will be a crutch that can hinder someone. Perhaps nothing should be done about it from Alpine.

[Jipok]

Found a hack that helps curb unwanted behavior. Not perfect, but at least something.

window.addEventListener('pageshow', function (event) {
    if (event.persisted || performance.getEntriesByType("navigation")[0].type === 'back_forward') {
        document.documentElement.innerHTML = '';
        location.reload();
    }
}, false);

Thanks @SimoTod

[SimoTod]

I think you can also try yo set Cache-control to no store to prevent your browser to take a snapshot of your page and force a clean page every time.

…

On Sun, 23 Feb 2025, 12:04 Jipok, ***@***.***> wrote: Found a hack that helps curb unwanted behavior. Not perfect, but at least something. window.addEventListener('pageshow', function (event) { if (event.persisted || performance.getEntriesByType("navigation")[0].type === 'back_forward') { document.documentElement.innerHTML = ''; location.reload(); }}, false); Thanks @SimoTod <https://github.com/SimoTod> — Reply to this email directly, view it on GitHub <#4552 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJRWJ4B2YKUH32TWDDBQ32RG2LZAVCNFSM6AAAAABXVJ5UN2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRZGEYTSNI> . You are receiving this because you were mentioned.Message ID: ***@***.***>