Detach conversations into separate Windows

@subesokun commented on Wed Sep 02 2015

It'd be awesome if there would be a way to detach group and private conversations into an extra Browser Tab/Window. This might not sound very useful for the Browser version of Rocket.Chat but it would be an awesome feature for the Electron desktop application. Once the Rocket.Chat core is capable of opening conversations into a separate tabs or windows, then it would be very easy to detach a given conversation via Electron into a separate Window as well. From UI perspective this could be maybe realized via a "detach" button in the title bar of the message container.

Any thoughts?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

---

@engelgabriel commented on Wed Sep 02 2015

Maybe using what @sampaiodiego is developing for the external chat window

---

@subesokun commented on Sun Sep 06 2015

Sounds interesting :) Will this external chat window be some lightweight version of the message container or will it have same feature set like starting video calls, edit messages, ...? In case of the Electron desktop application it should provide the same features as the none detached version of the message window. So it has to boot somehow kind of the same Rocket.Chat "kernel/core" like the full application.

Thanks for considering this feature request!

---

@engelgabriel commented on Sun Sep 06 2015

Thinking again, the external chat window has very limited features, it would no make sense to use it. We just need a different route on the existing main project. Not sure if the communication could be done via the parent window or should it create its own connections? Opinions?

---

@Sing-Li commented on Sun Sep 06 2015

Opinion. I think once we have that, users will want to embed a 'frozen version' of a mini-chat into other single page web apps. To do that, the bundle will be a bitmap plus meta-data state save to reconstitute the frozen chat session. So my vote is for separate connections.

It will allow reconstitution (unfreeze) within the other app, inside an embedded browser or webview as well.

---

@geekgonecrazy commented on Sun Sep 06 2015

Most pop out windows i've seen in chat type applications rely on the parent window. I think this is perfectly reasonable. Reduces the amount of connections to the server. We already have an always open socket.

Now for embed-able solutions it'd for sure have to be seperate. I was just thinking along the lines of popping out the window so you always have that conversation visible, while still being able to look at others.

---

@subesokun commented on Sun Sep 06 2015

In case you've a chat server with lots of active clients then each separate connection per user could really hurt :/ But saying that I'm not really sure how a child window can rely on the parent window to share a connection. Maybe with Electron you can build such a bridge but usually in the browser you won't be able to do that by default or only with ugly and insecure browser extensions.

Maybe the Service Workers can be a solution to this problem as it seems that a Service Worker instance can be shared among several tabs. This way you'd need to create only one server connection in the Service Worker which can be then "shared" among the tabs. It would be interesting to know if they can be also shared among window instances in case of Electron... Also I'm not really sure how well Service Workers will work together with the Meteor DDP or if Meteor has any plans to support them in future.

---

@geekgonecrazy commented on Sun Sep 06 2015

Its not so much share a connection as it is communicating with the parent window, then the parent window handles send / receive.

---

@engelgabriel commented on Mon Sep 07 2015

Probably we would want to implement a test, to see if the communicating with the parent window is available and use it, if not, open a new connection. That would be the ideal world, but not sure how feasible it is.

---

@geekgonecrazy commented on Mon Sep 07 2015

http://davidwalsh.name/window-postmessage

This looks to be one way of doing so.

---

@Franziskus1988 commented on Mon Sep 26 2016

@geekgonecrazy We tried to use this in our company and had problems with IE.

You could think about using MessageChannels [https://developer.mozilla.org/de/docs/Web/API/MessageChannel] instead.

Start by reviewing the discussion about detached conversations, Electron windows, and the existing parent-window communication model. Compare the proposed postMessage and MessageChannel approaches, then define the window, routing, and connection behavior needed for a detached conversation to retain the main message-container features. Done means the design is agreed and the feature works without an unresolved connection strategy.