Context-Aware, Not Everywhere: How Browsy Decides Where Its Tools Show Up

Open a Gmail draft, select a sentence, and Browsy’s toolbar appears next to it within a beat. Select the same amount of text in a news article on the same page load, and nothing shows up. Same extension, same tab, same click pattern — different result. That’s not inconsistent behavior; it’s the intended one, and it comes from a single question the extension asks before it ever renders anything: is there actually something to do here?

This post is about how that question gets answered — what “editable text” means in practice, what happens when you select something, and why the toolbar’s absence on most of the page you’re reading is a deliberate design choice rather than a gap.

The rule every writing tool shares

All six of Browsy’s writing tools — covered in more detail in the field guide — key off the exact same condition: an editable selection. Concretely, that means two things have to be true at once:

1. You’re focused inside a field the page allows you to type into.
2. You have text selected inside that field.

Neither one alone is enough. Clicking into an empty compose box with nothing selected doesn’t trigger anything, because there’s no text to act on yet. Selecting read-only text on a page — a paragraph in an article, a comment you didn’t write — doesn’t trigger anything either, because there’s nothing there Browsy could write back into. The toolbar isn’t reacting to text; it’s reacting to text you’re in a position to change.

What counts as “editable”

“Editable” covers more than it might sound like at first: plain <textarea> elements, text <input> fields, and contenteditable regions — the technique most rich-text editors use, including Gmail’s compose box, most CMS and blog editors, and comment boxes on sites that don’t use a plain form field. If you can place a cursor in it and type, it’s very likely editable in the sense Browsy cares about.

A few things deliberately don’t count, and it’s worth knowing them so an absent toolbar doesn’t read as a malfunction:

• Read-only or disabled fields. A form field that’s filled in but locked — a confirmation screen showing your submitted answers, for instance — is skipped even though it looks like a normal text field.
• Non-text inputs. Checkboxes, radio buttons, file pickers, color and range sliders, and similar controls aren’t text fields at all, so there’s no selection to act on inside them.
• Plain page content. The body text of an article, a static product description, someone else’s comment — anything you can highlight but not type into.

This is also why the same page can behave two different ways depending on where your cursor is: a support site with both a read-only knowledge-base article and a live chat box will show nothing when you select article text, and the full toolbar the moment you select something you’ve typed into the chat box.

What happens when you select text

For a plain <textarea> or <input>, the browser tracks selection internally (selectionStart/selectionEnd) rather than through the same mechanism it uses for ordinary page text — so Browsy reads it from the field directly rather than relying on a generic page-wide selection check. For contenteditable regions, it uses the standard browser selection API instead. Either way, the result feeds into the same downstream check: is there a non-empty piece of selected text, and is the field it’s in one you’re allowed to edit. Once both are true, the toolbar renders next to your selection, and the same signal is what makes the right-click “Rewrite with Browsy” style menu items and the command palette entries relevant, too — all three entry points described in the field guide read from this one answer rather than each doing their own detection.

None of this runs on a busy loop watching the page for changes every few milliseconds. It’s triggered by the events that actually matter — a selection changing, a field gaining focus, the page navigating to a new view in a single-page app — and debounced so rapid-fire events don’t each trigger a fresh check. The result is cached against the current page state and only re-evaluated when something on the page actually changes, which is the difference between “responsive” and “constantly costing you battery and CPU on tabs you’re not even using.”

A wider recognition than today’s tools use

The detection layer underneath this is built to recognize more than just editable text — it can already tell a YouTube watch page from a GitHub repository page, a Google Doc from a PDF, an email inbox from a generic contact form, a chat app’s message log from an ordinary page. That’s deliberate groundwork: the same engine that gates today’s six writing tools on “is there an editable selection” is built to answer a much broader set of “what kind of page is this” questions, so that a future tool built for, say, PDFs or video pages doesn’t need to invent its own page-sniffing logic — it reuses the same detection layer everything else already goes through.

Worth being precise about what that does and doesn’t mean today: recognizing a page type isn’t the same as having a tool that acts on it. Right now, every shipped tool in Browsy keys off the identical editable-selection condition described above — there isn’t yet a PDF-specific or video-specific tool wired to those other signals. Think of it as load-bearing infrastructure for what’s next, not a preview of a feature that’s already live.

Why gate anything at all

The alternative — showing a floating icon or a persistent panel on every page regardless of whether there’s anything to do — is the more common pattern among AI browser extensions, and it’s the one this design specifically avoids. A toolbar that’s available everywhere is also a toolbar you have to visually filter out everywhere, on every page load, whether or not you have any use for it in that moment. Gating visibility on an actual, checkable condition — can this text be edited, is any of it selected — means the toolbar only asks for your attention when there’s a real action behind it.

It’s the same instinct behind the six separate writing tools instead of one general-purpose chat box: narrower, more specific triggers over broad, always-on ones, applied here to when the tools appear rather than what they do once they have.

If the toolbar isn’t showing up

A short checklist for the most common reason it’s absent when you expect it:

1. Check you’re actually focused in the field, not just near it. Clicking a comment box’s border doesn’t count as focusing it; click inside the text area itself.
2. Confirm you’ve selected text, not just placed a cursor. An empty cursor position has nothing to act on — drag or double-click to select something first.
3. Check whether the field is disabled or read-only. Some sites render form fields that look editable but are locked until a later step.
4. Try the right-click menu or the command palette instead of waiting on the inline toolbar. All three read the same underlying signal, so if one entry point seems unresponsive, the other two are worth trying before assuming something’s broken.
5. Reload the tab after installing or updating the extension. Content scripts attach when a page loads, so a tab that was already open beforehand won’t have picked up a fresh install. This is the same content-script mechanism covered in the permissions guide — it’s also why the extension needs host permission on the pages it runs on in the first place.

None of this requires digging into settings or filing a bug report. In the large majority of cases, “the toolbar didn’t appear” traces back to one of the two conditions at the top of this post not actually being met yet, not to the detection breaking.

---

Curious how this fits into the rest of the architecture — where the detection runs, what it’s allowed to see, and what stays entirely on your device? Privacy by Architecture covers the background service worker and content script boundaries that everything described here runs inside of.