Switching Tabs and Split Panes From the Keyboard in Overlay
If you use Overlay with a split tab, say a chat on the left and docs on the right, you may have hit this: switch panes from the sidebar, start typing, and the text goes into the other pane. Or switch tabs and press space to scroll, and nothing happens until you click the page first.
That's fixed in Overlay 2.0, and there's a new shortcut to go with it.
Typing goes where you are
The rule is simple now. The pane with the blue outline is the pane that gets your keyboard, however you got there. Click it, pick it in the sidebar, click its badge in the corner, or use a shortcut: typing, space-to-scroll and the page's own shortcuts all go to that pane.
A few everyday cases that used to need an extra click:
- Type a URL into the new-tab page or the address bar and press Return. You can scroll or type in the page right away.
- Press ⌘L to peek at the address bar, then Esc. You're back in the page.
- Close the pane you're in. The pane that takes its place gets the keyboard.
Overlay still doesn't take the keyboard away from the app you're working in. Summoning the panel doesn't steal focus, and none of this changes that; it only decides which pane inside the panel gets your keys once you're using it.
Moving between panes
| Keys | What it does |
|---|---|
| ⌘⌥] / ⌘⌥[ | Next / previous pane in the current split |
| ⌘⇧] / ⌘⇧[ | Next / previous tab |
Pane switching goes in reading order, left to right and top to bottom, and wraps around. If the current tab isn't split, it does nothing; it never jumps to another tab. Tab switching is the other way round and skips over the panes of a split, so one press always takes you to a different page.
Both pairs can be changed in Settings → Shortcuts, under Customizable. If you'd already customized or removed some shortcuts, those stay as they were after updating, and the new pane shortcuts start on their defaults.
To make a split in the first place, press ⌘\ on a tab, or drag a tab from the sidebar onto the edge of a pane.
Background tabs rest
A related thing you might notice. Pages in tabs you aren't looking at slow down, and so does everything while the panel is hidden: animations stop and timers run only a couple of times a second. That's how Safari treats background tabs too, since Overlay uses the same engine. If a dashboard in a background tab looks a few seconds stale when you switch to it, this is why, and it catches up once it's on screen. Every pane of a split counts as on screen.
One thing that still behaves differently from a browser
When Overlay is open and you switch to another app without hiding it, the pages inside still think you're looking at them. A browser would tell them you'd left. Overlay doesn't, because doing so would break hover effects on pages while the panel sits beside your work.
For most sites it makes no difference. Some chat apps use exactly this signal to decide whether to send a notification or mark a message as read, so while Overlay is on screen they may assume you've seen things you haven't. If you rely on notifications from a chat site, hiding the panel with your shortcut when you're done with it gives the page the right signal. We're watching for reports on this and have a possible fix, but haven't shipped it.
When this isn't the tool
Overlay is a panel of web pages that floats over your work. It isn't a full browser. If you want deep keyboard control of pages themselves, like link hints or vim-style navigation, a browser extension in Chrome or Safari does that and Overlay doesn't try to. What Overlay does try to get right is the part a browser gets right without thinking about it: the tab you're on is the one you're typing into.