Allow guests to collaborate on multiple remote buffers (Part 1) #262
Conversation
This is a temporary stopgap measure until Atom supports batched marker update events.
As of 4b3379c, this functionality lives in GuestPortalBinding.
This will prevent "Workspace can only contain one instance of object" errors if the leader switches to a remote editor that has been moved into a pane that is inactive when `updateTether` gets called.
This will prevent "Workspace can only contain one instance of object" errors if the leader switches to a remote editor that has been moved into a pane that is inactive when `updateTether` gets called.
This prevents a bug that was previously causing followers to disconnect their tether when the leader rapidly switched among tabs and destroyed them before followers had the chance to download the remote editors/buffers associated with them. In particular, followers would receive two messages indicating that the leader wanted to switch to a new tab and that they wanted to close the previous one. When trying to download the editor associated with the new tab, the guest would find out that such editor did not exist anymore and, therefore, would skip that message and only process the second message indicating that the old editor needed to be removed. In doing so, it would remove the old editor from the workspace and call `portal.activateEditorProxy` with the editor proxy associated with the newly active pane item in the workspace. In turn, this would cause the follower to disconnect their tether, even if the two peers did not really want to start browsing tabs on their own. With this commit we are explicitly preventing this problem from happening by not relaying active editor changes to `portal` when such changes happen as a result of an update to the workspace caused by the leader while the tether is retracted.
|
Exploratory testing revealed a handful of issues for us to address:
|
|
good finds! me and @rsese are going to spend some time testing this tmrw! @jasonrudolph Do you think we should wait until the issues above are address before doing testing on it or would still be good to get extra 👀 on it? |
@ungb: I'd love to have you test it out after we address those issues. If you want to also test it out before we address those issues, that's totally welcome. 😄 |
|
Thanks @jasonrudolph! I'll take a look today and let you know if I find anything. I'm going to reschedule the meeting with me and @rsese to next Tuesday. I'll follow up with you guys on Tuesday if the PR isn't ready I can push the meeting out. |
Prior to this change, if I host split an editor and then closed one of the two tabs for the editor, the remote editor on the host would have its title changed to "untitled". With this change, we keep track of how many remote editors we have for a remote buffer. When we deremotify the last editor for the buffer, we deremotify the buffer as well.
|
@as-cii and I discussed the rollout strategy for these changes. Here's our current plan:
|
When the guest closes the last remote editor or the portal's empty pane item, leave the portal. Prior to this change, if the guest closes the last remote editor, the guest would be in limbo: they're still in the portal, but they don't see any remote editors. Their only remedy was to manually leave and re-join the portal. In an upcoming release, we hope to integrate the guest's fuzzy finder with the portal. Once that functionality is in place: - If the guest closes the last remote editor, the guest could use the fuzzy finder to open any of the available remote editors, thus preventing the limbo state described above - Because of this, we could remove the behavior implemented in this commit (i.e., we would no longer have to leave the portal when the guest closes the last remote editor)
|
Nice work @as-cii and @jasonrudolph. This is going to be a huge improvement. |
Demo
Description of the Change
This pull request implements the core parts of the functionality described in RFC-001:
Coming in future pull requests
The following features of RFC-001 will be addressed in future pull requests:
Alternate Designs
See RFC-001
Benefits
See RFC-001
Possible Drawbacks
See RFC-001
Verification Process
Applicable Issues
#231: Introduced RFC-001.
#211: Requests sharing entire project. This pull request doesn't allow you to automatically share an entire project/folder, but we anticipate that this will be a useful interim improvement for many people that are interested in sharing a whole project.
TODO
package.jsonto depend on new version of teletype-client🍐'ed with @as-cii