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.

[adamziel]

@akirk Counterpoint: you couldn't refresh the page to scrap your temporary site and start over from the same blueprint. We'd need a different behavior for temporary sites and stored sites, and that sounds confusing.

[bgrgicak]

@akirk Counterpoint: you couldn't refresh the page to scrap your temporary site and start over from the same blueprint. We'd need a different behavior for temporary sites and stored sites, and that sounds confusing.

What if we introduce subdirectories /site-slug/ that will open saved sites in seamless mode?

The idea is that you could go to playground.wordpress.net/my-site/wp-admin/ and it would always open the same site and page.
The main drawback I can think of is that It wouldn't allow us to use the query API, but it would be a more "natural" experience of using WordPress.