Support multiple windows in the same datafolder

[ByJumperX4]

Checklist

• [x] I searched the :help documentation using / for helpful information
• [x] I have read the frequently asked questions
• [x] I did not find any similar issues in the issue tracker

Addition or change I'd like to have multiple windows of vieb opened, as I have 4 screens. With , I can tear off a tab to create a second window using the mouse, and put that window somewhere else. I like to watch a video and do some researchs at the same time.

[Jelmerro]

Having multiple windows for a single datafolder isn't supported at the moment. You can however open new instances in different folders using the --datafolder startup argument. If desired you can share settings by making a user viebrc instead of using the one in the datafolder (see :h viebrc). You can also customize these instances to open specific tabs on startup with a custom icon or name, by making an erwic config for it. Finally, depending on your screen layout, it could work to use window splits to achieve something similar (see :h splitting).

I know this isn't exactly what you describe, but it's the closest Vieb offers at the moment. Dragging actions with the mouse are not something that's planned in the near future, as Vieb's main strengths and focus points are keyboard-based actions. Multiple windows in the same datafolder is at the moment asking for conflicts, and is as such disabled by redirecting the urls to the existing window.

There are many core concepts that would need to be reworked to make sense in a multiwindow context without conflicting, such as tab restore, history storage and even keeping settings in sync between all opened windows. I won't be working on this, as I don't think it's worth the trouble over just using multiple datafolders with the added bonus of keeping data separate for different purposes, but PRs are welcome.

[stevkazt]

This is a feature I've been missing since I started using Vieb, can you guide me about what should I check in order to implement multiple windows. Thanks!

[Jelmerro]

It's probably never going to happen, Electron does not support this use case and it's going to need a lot of work to manually override all file access to the datafolder (if even possible for browser things like localstorage etc). See https://github.com/electron/electron/issues/4727 and it's linked issues for more info.

[Jelmerro]

I have added an option for this, but keep in mind using separate datafolders will ALWAYS be recommended over using this, see the new FAQ entry for details: https://github.com/Jelmerro/Vieb/blob/master/FAQ.md#why-cant-i-open-multiple-browser-windows

[mentalisttraceur]

There's something here from an architecture perspective that I'm having difficulty wrapping my head around:

1. At the OS level, the relationship between processes and windows is one-to-many - a single thread in a single process should be able to open multiple windows.
2. And there do seem to be ways to get Electron apps to open multiple windows, see for example:
   • https://www.electronjs.org/docs/latest/api/window-open
   • https://github.com/tamkeen-tms/electron-window-manager

So from a naive outside view, I would think that there shouldn't be any fundamental reason why one Vieb process couldn't render multiple windows and have the data folder work the same across windows as across tabs - so what am I misunderstanding or missing?

[Jelmerro]

I believe I have explained this clearly in the FAQ, but basically it's not supported by Chromium's storage system, in that it either places locks that are not released till the app closes, while other things are no locked at all meaning you will run into race conditions. This has little to do with Electron nor the OS, but does mean that if you want multiple windows to interact safely you would need to safe-guard it yourself. While this is not impossible, it's far beyond the scope of what I would same sane to work on, when even the Electron devs themselves recommend to keep a single instance app. Just for cookies for example, this would mean freezing the storage for one window to release the lock, wait for that to resolve, then modify it in the other window, and have this hell back and forth. That's just for cookies, and even a single mistake would corrupt and thus reset all cookies, let alone all the Vieb specific code that would need to follow the same principles, since inter-communication between separate windows is minimal in Electron and would need to be handled at file-level with locks. This is not something I can warrant to implement, unlike the Chrome team. I have offered a startup flag to ignore this safety feature, you can see for yourself how unstable this will be. If you aren't big on cookies/localstorage maybe you won't notice the difference, if so, great that's exactly why I added the option. But I won't make this the default option for all users without them clearly knowing the side effects and risks of having multiple processes/windows interact with the same folder.

[Jelmerro]

To add: Any Electron app that does allow multiple windows probably does not use a lot of Chromium specific data storage such as localstorage or cookies, but usually implements it's own storage and settings, for which there are plenty of npm packages that do this safely without relying on Chromium's locking. But for a browser project implemented in Electron I do need the native browser features, so I do currently not see how this could be safely implemented.

[mentalisttraceur]

Sorry, I think we might be talking past each other.

I understood that use of Chromium's features seems to be somehow getting in the way. I had already read the FAQ and your comments on #430. What I'm trying to understand is more precisely where and how.

What I hear you telling me is that creating a second window introduces race conditions in managing non-UI state like cookies.

But my domain knowledge is lower in the tech stack, and I am confident that a process just telling the OS to create a second window, and then drawing some pixels and handling events there too instead of just in the first window, cannot in itself introduce any new non-UI races.

I also know that Chromium self-inflicts non-UI race conditions on itself because it goes out of its way to create a new process for each window (and each tab, I think) - but that's inherent to forking a new process, not to opening a new window, and I'm not sure if we are forced to do the same in Vieb?

[mentalisttraceur]

~~Could you point me at the spot where opening a new tab is implemented?~~ Edit: I think I found it!

I might be able to answer my questions faster and without troubling you further by playing with the code once I have that.