is this ready?

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

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.

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?

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.

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

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

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.

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

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)

Makes sense @leex279, thanks for the heads up!

@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"

Hi Guys,

I have made some tweakes (did not ad the code in this PR)i but here is a screenshot :

Predefined Window Sizes:

Size Selection UI:

Main button opens preview in current size
Dropdown button shows size options
Each size option shows dimensions
Clean dropdown menu styling

Usage:

Click the main button to open in current size
Click the dropdown arrow to see size options
Select a size to open in that dimension
Window opens with clean UI (no browser chrome)
The new UI looks like:

Try it out:
Click the dropdown arrow
Select a device size
Preview opens in a new window with those exact dimensions
Each size gives you a different viewport for testing

Br,

Stijn

@Stijnus looks nice. Add them in a new PR, so we can test it out :)

@Stijnus looks nice. Add them in a new PR, so we can test it out :)

Give 30 min will update soon finishing other Dev project first :)

Hi, I have update the PR please test if you have the time :)

Br,

Stijnus

Merged 🎉
What a great contribution. Thx, @Stijnus

Interested to see whether this work on electron too, @thecodacus

Interested to see whether this work on electron too, @thecodacus

I am also not sure. 😅

Merged 🎉 What a great contribution. Thx, @Stijnus

Interested to see whether this work on electron too, @thecodacus

Thank you...

a mention in the readme would be nice 😊

this works with that also.

a mention in the readme would be nice 😊

ohh man why didn't you update it.., I will add it on my next PR

this works with that also.

a mention in the readme would be nice 😊

ohh man why didn't you update it.., I will add it on my next PR

my bad... thank you

@Stijnus just saw the contrast is very bad for dark mode:

maybe you can fix that in another PR :)

Then don't forget to add yourself to the readme ;-)

Just in time before I do my next video :D thanks.