Stored key is lost on Brave browser when hitting F5

[cadilhac]

As title says... This is the only browser where I have this problem. I have also tested with Brave Shields off for my page.

[franky47]

What do you see after F5 when you type window.name in the console?

[cadilhac]

Empty string. Same after I have reentered my key and it's supposed to be saved in your store.
But I get this empty string on Chrome also...

[franky47]

I can't reproduce it in either Brave or any other browser, using this minimal repro:

import SessionKeystore from 'session-keystore'

const store = new SessionKeystore()

export default function App() {
  return (
    <>
      <div>
        <button onClick={() => store.set('test', 'pass')}>Write</button>
        <button onClick={() => alert(store.get('test'))}>Read</button>
      </div>
    </>
  )
}

Screen.Recording.2025-10-30.at.21.47.54.mov

Could you try and open a minimal reproduction repository that I could look at please?

[cadilhac]

This is good news. So I will investigate and see if I'm breaking something somewhere...
When running 'window.name' in the console or watches, is the browser supposed to return a string? I don't get that even when working in chrome.

[franky47]

Oh my bad, it's actually cleaned up after the page has finished loading, to avoid leaving either half of the "encrypted" store dangling:

session-keystore/src/utility.ts

Line 60 in 85887f3

window.top.name = json === '{}' ? '' : json

So unfortunately there isn't a lot we can use as-is to debug this (since it all lives in memory and only persists while the page reloads). You could try and add some console.log statements in the node_modules to see if it manages to save/load correctly.

[cadilhac]

I'm trying to modify your code in nodes_modules but it's not taken into account. I am in a Vue app, bundled by Vite, so not sure...

[cadilhac]

ok, I cloned your code and injected it into my own code. I can now trace and console.log.
Something strange. In chrome, the unload handler, and therefore persist is correctly called. Not in Brave.

[cadilhac]

Could it have a link with the following: https://developer.chrome.com/docs/web-platform/deprecating-unload ?
I have added my own beforeunload and unload handlers in my app. In Chrome, both are called. In Brave, only beforeunload is called.

So just to test, I replaced your unload with beforeunload (even if the document above says it should not be used either). This time, it's called and window.name is valid at the end of persist. Unfortunately, it's empty when load() is called after the refresh...

PS: I am on Brave 1.84.132 for Windows. So I tested Brave in a MacOS virtual machine and it works well, like you. On Android it fails.
I think it was worth filing a bug report at Brave.

Please tell me if you can reproduce that. And what do you think about the deprecated unload event?

Ici Montréal, à vous Grenoble ! ;)

[franky47]

I replaced your unload with beforeunload (even if the document above says it should not be used either). This time, it's called and window.name is valid at the end of persist. Unfortunately, it's empty when load() is called after the refresh...

Yeah that sounds like a bug if it only occurs on Windows & Android. Thanks for reporting it.

And what do you think about the deprecated unload event?

I guess we could move it to onbeforeunload, if we know that the window.name property persists. Otherwise we'd have to find another way that doesn't get written to disk to pass the other half of the store to the new JS context. history.state could be a possible candidate, as it doesn't get written to the global browser History if the URL doesn't change. But client-side routing frameworks often keep stuff in there and it may break to try and mess with it.

[cadilhac]

Moving it to onbeforeunload sounds reasonable. Let's cross the fingers that Brave's team will acknowledge the bug and fix it. This is a quite serious bug I think as it may have broken many sites relying on window.name.

[franky47]

To be fair, piggybacking on window.name is kind of a hack based on an old browser feature.

[cadilhac]

In my app I changed your lib to use history.state instead and it works great.

[cadilhac]

Oops, I was doing a simple history.state.keyStore = ... and I thought it was working fine. It was actually, but for an unknown reason, I can't make it work like this anymore. Here is what seems to work now:

const saveToHistoryState = (name, data) => {
	const obj = loadObjectFromHistoryState()
	obj[name] = data
	const state = history.state
	state.keyStore =  JSON.stringify(obj)
	history.replaceState(state, '', window.location.href)
}

But it works only for a Refresh. If I edit the url in the address bar of the tab to go somewhere else in my app and then come back to the page where I need the key, it's lost. window.name was working in all cases.

[cadilhac]

Seems fixed in Brave, although I can't find a mention in the Brave changelog.

Someone mentions that window.name should be retained if, in a tab, we visit another domain and then come back to our domain. This still does not work in Brave, but should it really? Doesn't work on firefox either...