Reflect the current URL in the browser navigation bar

[adamziel]

At the moment, the top URL bar only says index.html, and all the navigation happens inside of an iframe. It would be great to have a feature that would update the top-level navigation, perhaps via pushState. It needs to be optional because updating top-level navigation doesn't make sense in contexts like runnable code examples.

[gziolo]

It needs to be optional because updating top-level navigation doesn't make sense in contexts like runnable code examples.

Yes, that would definitely make sense only in the context of the npm run dev where you don't have any other way to change the URL. Actually, that was my primary issue – I wanted to navigate to a specific URL.

[adamziel]

I wanted to navigate to a specific URL.

This is now easy with wordpress-browser.html that has an address bar widget.

It could also work in a seamless mode via pushState(), but the service worker would have to be smart about page refreshes. At the moment, it would attempt to forward the request to WordPress, but it wouldn't find any instance. WordPress only lives as long as a tab with wordpress.html open.

The ServiceWorker would have to be smart about handling different types of requests:

• Iframe-originating requests: forward to a running WordPress instance
• Top-level requests: Create a new HTML page where a new WordPress instance would be started, use it to handle the original request

[krishenriksen]

It has been done in this commit:

bloqifi@352190c#diff-92f163a9d50e1c25a44764089df3a996a8ce10e7315f7f9ebe5d89554d52e245

[adamziel]

@krishenriksen good explorations! One tough nut to crack there is handle page refreshing. I haven't actually tested that commit, but I noticed it doesn't alter the service worker code, which means that refreshing the page or sending someone the link will display an error page – see my previous comment in this issue. Do you have any ideas how to approach that?

[krishenriksen]

@adamziel I am looking into page refresh, but an obstacle we / I must overcome first, is storing the db in indexeddb, so any page refresh will maintain changes.

[adamziel]

@krishenriksen I’d say data persistence is a separate issue from refreshing the page after pushState. Definitely worth addressing, too! Using IDBFS instead of the currently used MEMFS could help with that one.

[akirk]

Now that we have persistency, it would be great to work on this. This would mean that Playground could allow for a useful seamless mode and alos be more resistent to accidental reloads. If you reload the whole page in the browser by accident then we could at least navigate to the same page back again.