Stories from the team: the quirks we hit

When an agent shares their own screen, the customer needs a six-digit code to join. The obvious design is to create and show that code after the agent has picked what to share. It looks fine on a diagram. It hides a trap, though: in Chrome, choosing a browser tab in the picker can switch the browser's focus straight to that tab. The agent clicks Share, Chrome moves them into the shared tab, and a code that appears only afterwards, on the page they just left, can be missed entirely.

The fix was to change the order. The agent now sees the code next to the share button first, before the browser's picker opens, and then starts capturing. The picker itself is still the browser's and cannot be avoided, and anything Chrome focuses after the choice is outside our page. But the code is already in the agent's hands by then.

There is a related rule that came out of it: the agent's support session stays in one browser tab, and we do not open floating chat windows or extra tabs. The in-page chat cannot follow someone into a different tab or window that Chrome focused after the pick.

This one came from a real device. A customer on Microsoft Edge opened a support session, used the full screen control, and then saw the browser block the page with a warning. The home page had loaded fine, the connection to our server was healthy, and the address was ordinary HTTPS, so nothing looked wrong from our side.

Edge has a protection that watches for pages that look like technical-support scams, and it can leave fullscreen and warn. A page that shows a support code, asks a stranger to share a screen and goes fullscreen can look, to a classifier, like the thing it is meant to catch. We cannot see inside that classifier, and we cannot say exactly why it reacted.

What we decided was about what not to do. We keep a usable windowed way through the session, so fullscreen is never required. And we never tell anyone to switch off their browser's protection to get past a warning. If that protection ever gets in the way, the right answer is to stop and tell the agent. We cannot promise the warning will never appear again, because the decision is made inside the browser, not by us.

Customers have phones, so of course people tried to share from them. Our early messages told those customers to update their browser, or that no screen could be found. Both blamed the wrong thing. Phone and tablet browsers do not let websites capture the device's own screen today, so no update would have helped.

We now explain that before anyone taps anything, and we detect it by asking the browser whether capture is available, rather than guessing from the device name. If a phone browser ever gains the feature, it will be picked up without our doing anything. The page tells such a customer to tell the agent, who can prepare a consultation where the agent shares instead, or to open the page on a computer.

What we say publicly is deliberately modest. Watching a shared screen is expected to work on phones and tablets, but it has not been tested on every device, and we do not promise it for any particular phone.

Browsers reload pages. Networks drop for a second. Connection credentials get refreshed. Any of those can make a page open a new connection to our server a moment before the old one has finished closing. For a short while, one person has two connections.

The naive approach treats a closing connection as the person leaving. The unlucky order is this: the new connection joins, then the old one closes, and the old one's closing announces that the person has gone. The agent's screen can then show a customer as disconnected while they are sitting there perfectly well.

The lesson was to track presence by who has joined in a given role, not by individual connections. If a replacement connection for that role has already joined, the old one closing is not news. We also learned to tie each negotiation to the exact two connections taking part, so a late message from an old connection cannot be mistaken for an answer to a newer one. And a shared screen that is already running has to survive the swap of its connection, so the new one can send a fresh offer without asking the customer for permission again.

These are the unglamorous parts of real-time software. They are invisible when they work, which is why we write them down.

None of these problems showed up in a diagram of how the system should work. They showed up when real browsers, real focus behavior and real people met it. That is also why we keep our public claims small: consent-based sharing, a code that lasts three minutes, and no promises about every device.

If you would like the underlying mechanics, start with how browser screen sharing works, and the code-lifecycle article. To try it as a customer, enter your code. Teams can see the overview and pricing, and the screen-sharing guide covers what to do when sharing will not start.