feat: added the "Open Preview in a New Tab"

[Stijnus]

[thecodacus]

is this ready?

[Stijnus]

I did my testing on my end but Yes it should be ready but please to be sure test before you merge it.

thx,

Br,
Stijn

[leex279]

Nice on. works fine for me so far. Just one thing, but not a must => if the external preview is open, can we prevent from switching to the preview tab within the main ui? So stay on code editor.

[Stijnus]

Nice on. works fine for me so far. Just one thing, but not a must => if the external preview is open, can we prevent from switching to the preview tab within the main ui? So stay on code editor.

like a detach window function or how i need to interper it ? can you be more precise?

[leex279]

This I mean. When bolt is done with coding (finished the prompt), its automatically switching to preview, what I dont like when the external preview in a new tab is already open. Then I want to stay on code-editor.

[thecodacus]

just need to update the logic here if the preview is opened in another tab don't switch

[thecodacus]

this is bolt.new when the chat is hidden, might be good for another PR

[thecodacus]

I was thinking about it, i don't think there is any way to communicate between these two tabs. so don't know how this is possible. I suggest we merge this PR and open a separate PR to explore this concept.

[Stijnus]

I was thinking about it, i don't think there is any way to communicate between these two tabs. so don't know how this is possible. I suggest we merge this PR and open a separate PR to explore this concept.

ì was playing arround this today after the PR :

The fundamental issue is that the web app running inside the WebContainer iframe has its own isolated context, regardless of whether it uses localStorage or not.

Here's what's happening:

1. Each preview tab has its own isolated WebContainer environment
2. Changes made in one WebContainer environment don't automatically propagate to another
3. Even without localStorage, each iframe has its own memory/state
4. The WebContainer isolation is by design for security and stability

The current approach of trying to sync through the parent window's localStorage or broadcast channels won't work because:

1. The WebContainer iframe is isolated from the parent window
2. Each WebContainer instance is independent
3. We can't directly access or modify the state inside the WebContainer from outside

Possible solutions could be:

1. WebContainer API Communication:

   • Set up a message passing system between the WebContainer and parent
   • Have the WebContainer app emit state changes
   • Parent receives and broadcasts these to other tabs
   • Other tabs tell their WebContainer to update

2. Shared Backend Storage:

   • Instead of localStorage, use a shared backend storage
   • All WebContainer instances read/write to same storage
   • Changes would be visible to all instances

[leex279]

thanks for investigating and summarizing this. I just saw it works the same in bolt.new, so I assume this is correct what you found out.

@patak-dev but maybe you want to change/enhance this as well for bolt.new, then we can use it as well :P
=> #1101 (comment)

[patak-dev]

Makes sense @leex279, thanks for the heads up!

[mrsimpson]

@Stijnus sli.dev, a browser based presentation tool also uses BroadcastChannels for communicating changes across tabs and even windows and it's a very robust and responsive experience.

Would it not be possible to have a thin shell around the webcontainer which listens to the broadcast and then propagates to the webcontainer? Or is this what you meant with "Set up a message passing system between the WebContainer and parent"