Dumb DOM API questions

Does the beaker-plugin-safe-app free handles automatically once the URL changes? I have a test app that uses history.pushState internally and it seems after such a page switch the handles are invalid when calling the several window.safeApp functions.

Yes, the handles are freed upon page reload and tab closing.

1 Like

I see. However, by doing a pushState, the page is neither reloaded nor closed. Consider the following example (tested this in the browser):

(async () => {
    const handle = await window.safeApp.initialise({ id: '1', name: '2', vendor: '3' })

    history.pushState({}, 'page 2', '/page2')

    setTimeout(() => {
        // Somewhat later.
        await window.safeApp.connect(handle) // 'Invalid handle: 63b3e...'
    }, 1000)

Fair point and good find, @bzee. We’ll have to look at how we’re doing this :+1: to avoid that.

In the meantime, can you try with hash history perchance? I don’t think that will trigger the same events so might work.

1 Like

I am using a library that does the routing, and internally it uses pushState, with hashes. It still frees the handles.

Hey @bochaco, I’m trying to add a new entry to the container of my app by using the function insert but the new entry doesn’t persist when I call getOwnContainer->getEntries again. Note that I can see the new entry if I use the same md_handle, it just doesn’t persist if I reload the md_handle.

Is it ok to add an entry to a container or should containers be used exclusively as files using the NFS API?

I’m using the mock network btw, any idea?

Hey @DavidMtl, are you committing the mutation with applyEntriesMutation on the container’s MD?

Ah okay, but according to the doc it should commit to the network directly.

So what’s the difference between using safeMutableDataEntries.insert and safeMutableDataMutation.insert? Is mutation used when we need to do multiple changes within a single “transaction”?


Yes, that should be corrected.

Yes, that’d be the case, if you want/need to populate the mutations object with several actions and then commit it to the network to make it more efficient.


What happens if applyEntriesMutation is never called?

The safe_client_libs manages an object cache in memory, so those changes are actually kept there until you send a request to commit them to the network.
This cache is intended not only for the purpose of trying to make a more efficient use of the network, but it’s also required for the FFI interfacing with the upper layers (e.g. the safe_app_nodejs lib/package). Every object is instantiated at the safe_client_libs layer, and the safe_app_nodejs just manages handles provided by it (they are kept within the Javascript objects the apps interact with, so it’s transparent to them). This is analogous to what happens between the browser’s safe_app plugin and the exposed DOM API.


You mean the doc or the behavior?

The doc, I’m sorry about that.


So what do you expect to happen - out of memory error at some random point? Might be better to have a limit on the cache and throw a specific error that this has been reached, or to force a commit (probably not!)

And if the browser tab is reloaded before the call to applyEntriesMutation those changes are lost?

It would be useful to know the expected behaviours (in the docs).

Yes, the safe_client_libs has a size cap and it’s an LFU cache.
I wouldn’t agree on the auto-commit in this case though, and it you are really unlucky to get your changes removed due to the LFU mechanism before you could commit them (which I think it’s not being unlucky but actually using a very inefficient app which keeps storing things in the cache without committing them, right? is my reasoning correct…?) then you should get an error when trying to commit as you would be referencing objects/data that doesn’t exist in the cache anymore.

Correct, because we clean all objects created by the app to prevent a mem leak caused by apps not freeing the objects by invoking the DOM API free functions.

1 Like

@happybeing, it sounds to me you are taking the discussion towards transactions for mutations/changes, is that right? :slight_smile:

I’m not sure what you mean. I’m just trying to clarify how things work - no agenda or significant opinions here. It’s not something I know much about, hence the dumb questions! Thanks for taking time out to answer - as always.

I was just kidding, when replying I started thinking about how having transactions could be applicable to some of this scenarios, like if instead of keeping some changes on the cache you send them to the network but as part of a transaction, which could somehow be rolled-back if the app decided to, or when the tab is refreshed and the connection with the network lost. But I’m also thinking that unless the app could recover an unfinished/uncommitted transaction, perhaps to continue acting on it, then the local cache should be good enough.


Hey @bochaco, the function authorise doesn’t work anymore. In the API playground I run initialise then authorise and then it gets stuck there. Do you have the same problem on your side?

Hey @DavidMtl, I just gave it a try and it’s working for me. If you still have issues please provide a more detailed explanation of the steps you made on the playground tool. Also based on other post from you, I get you are building the browser yourself, just trying to narrow it down, can you please validate if the issue also happens with the browser we released?