Browser goto only works once, then stops

Wappler General How To
#1

I am unsure if this is a bug or me not clearing something properly.

I have a form, on success it clears the form and then does a goto to get to another internal page with this

<form method="post" id="product_import" is="dmx-serverconnect-form" action="/api/booking-providers/set-product-import-list" dmx-on:success="product_import.reset(true);browser1.goto('/product-settings')">

On the first submission of the form, it indeed redirects the browser to the next page, however if later on I go back to that same form, and choose some different options, and then submit again, it just resets the form and never does the browser redirect to the next page.

Anyone got any idea why?

#2

Would the first check be to test this in several different browsers?

1 Like
#3

I figured it out, was slightly unexpected behaviour, but i had to change my navigation from
<a class="dropdown-item" href="/product-import" internal>Import</a>
TO
<a class="dropdown-item" href="/product-import">Import</a>

Removing internal removed the ?fragment=true query string and now it works the same each time, on success it redirects as I want.

1 Like
#4

Is the previous URL the same as the next URL?

#5

Yes, the redirect url is static, so after any import of a product from the API it should redirect to the additional settings page to complete the setup.
If the user wants to then add another product to import 10 minutes later, they can, and it should go back to the exact same page url for them to do part 2.

EDIT: I realise that may sound a little ambiguous, because it would make logical sense that the settings are relevant to the product just imported, but I have not made it that smart just yet.
The product settings page, just shows a list of all the imported products, and the user can click the one they want to edit, so it is a static url right now, but i will possibly alter it later to something better.

#6

I’ll second this. I have had issues where Safari’s new intelligent script blocking just completely ignores a second run of the same script without refreshing the page when using standard libraries.

If it turns out to be Safari only, we’ve gotten around this by adding a hidden value that causes the page to refresh by checking whether there’s a stored value of “submitted_formX” in the browser. If this value is true, we show the form with data pulled from the database so it can be edited.

Removing internal sounds like it is causing a refresh, rather than treating it like an SPA. I had originally added more of an explanation and then re-read your use case and it sounds different.

1 Like
#7

Thanks nomad, I did test my use case in 3 browsers and each was doing the same thing, but as you mention, removing the internal just treated it like a semi refreshed page rather than an SPA and kind of bypassed the whole issue.

1 Like
#8