Problem
The React Grab toolbar renders in a fixed position (bottom-centre of the viewport). That's the same spot occupied by several popular always-on-top desktop utilities — in my case Wispr Flow, whose dictation bar sits bottom-centre and floats above the browser window.
The result is a permanent overlap: the dictation bar covers the Grab toolbar, so I can't click it without first moving or dismissing the other tool.
This isn't specific to Wispr — bottom-centre is a common home for floating dictation bars, screen-recorder controls, and OS-level pickers, so any of them will collide.
Proposal
Let the consumer choose where the toolbar mounts. Roughly in order of how much I'd value them:
- A position option — a corner/edge preset (bottom-left, bottom-right, top-left, top-right, bottom-center) picked at init time. Covers the collision case with almost no API surface.
- An offset escape hatch — e.g. accept a custom class name or style object on the toolbar container so we can nudge it in CSS ourselves.
- Drag-to-reposition — let the user drag the toolbar and persist the choice to localStorage. Nicest UX, most work.
Problem
The React Grab toolbar renders in a fixed position (bottom-centre of the viewport). That's the same spot occupied by several popular always-on-top desktop utilities — in my case Wispr Flow, whose dictation bar sits bottom-centre and floats above the browser window.
The result is a permanent overlap: the dictation bar covers the Grab toolbar, so I can't click it without first moving or dismissing the other tool.
This isn't specific to Wispr — bottom-centre is a common home for floating dictation bars, screen-recorder controls, and OS-level pickers, so any of them will collide.
Proposal
Let the consumer choose where the toolbar mounts. Roughly in order of how much I'd value them: