Device Layout Mode: What the Grey Button Does, and Why You Sometimes Need It

What's actually going on

Every browser on iOS, including this one, is required to use Apple's WebKit engine. That isn't a shortcut anyone took; it's the platform rule. And WebKit on iOS makes some assumptions about touch input that don't hold when the page is being driven by a synthetic cursor on a second screen.

The friction concentrates in embedded frames. When a site loads part of itself inside an iframe from another domain, a cookie consent manager, a payment form, an identity provider's sign-in box, an embedded video player, that frame is sandboxed. It receives events only through the browser engine's own input path, and there are cases where a click generated on an external display doesn't reach inside it.

This is not accidental on the sites' part, either. Isolating sensitive controls inside a cross-domain frame is a deliberate anti-fraud and anti-bot measure: it means an automated script running in the page can't reach in and click "Pay" or "Sign in". It works as intended, and the same mechanism catches a legitimate cursor coming from a second screen.

XeOS goes to considerable lengths to make this rare. Clicks are hit-tested through Shadow DOM, including closed shadow roots, which is what most cookie banners use, and focus is directed at the right editable host rather than a nested child, which is why text fields on chat and note-taking sites work at all. But a cross-origin frame that refuses synthetic input is a wall the app cannot climb, and pretending otherwise would just waste your time.

The workaround, in four seconds

So there's an escape hatch. Rather than making you unplug or give up on the page, XeOS hands that window to the screen it can drive perfectly: your phone's.

1. Click the grey phone button in the window's corner.
2. The page appears on your iPhone or iPad's own screen, in its normal touch layout.
3. Do the one thing that wouldn't work, accept the banner, tap the sign-in button, fill the card field.
4. Tap the return button on the phone to send the window straight back to the external display, exactly where it was.

Nothing reloads. You don't lose your place, your scroll position, or what you'd typed. It's a detour, not a restart.

Portrait or landscape?

You can choose which way the page appears on the phone. It's asked during setup and can be changed later in Settings.

• Landscape, recommended if you're using a physical mouse. You get more usable width on the phone for the moment you're over there.
• Portrait, recommended if you're using the on-screen trackpad, because it's the more natural way to hold the device.

When you'll actually need it

In practice, a handful of situations:

• Cookie and consent banners from third-party consent managers.
• Sign-in flows that hand off to an identity provider in a frame, "Sign in with…" buttons are a common one.
• Payment fields, which are almost always in a frame from the payment processor for exactly the reasons above.
• Embedded widgets, maps, booking calendars, chat pop-ups, from a different domain than the page around them.

Almost everything else, the site itself, its menus, its forms, its videos, works normally on the external display.

Why it's not a bug report worth filing

If you hit a page that won't take a click, it isn't something XeOS has failed to implement, it's a boundary of the browser engine every iOS app is required to use. The honest position is: it will not be fixed by an update to this app, because the app doesn't control that layer. What XeOS can do, and does, is make the detour as short and lossless as possible.

It's also temporary in the smallest sense, you're on the phone for one tap, then back on the big screen. Most people forget the button exists between uses.