This is a deep dive into a trivial annoyance that I didn’t end up solving. I think it’s worth sharing because learning where today’s AI tools and software platforms get in the way is part of learning to use them well. These boundaries will shift, but recognizing them as they stand can save you a lot of time and energy barking up the wrong tree. Here’s what I tried and why I eventually stopped.
I was looking at the response body of a network request in Chrome DevTools and wanted to copy a URL out of an HTML attribute.
I double-clicked inside the URL, expecting Chrome to select the contents of the quotes. Instead, it selected one of the fragments between punctuation marks. Triple-clicking selected the whole line.
Of course, I could click-and-drag across the URL or use shift-click to select the range. But the value already had the structure I cared about. I did not want to select an arbitrary range of characters; I wanted to select the thing inside the quotes.
Vim has a clean vocabulary for this: the command yi" means “yank inside quotes.” The editor understands the text object and finds its boundaries for me. DevTools does not. Its selection behavior follows lower-level lexical boundaries, which is reasonable as a general rule but does not match this particular intent.
Normally, I would do the manual thing and move on. Recently, though, I have become more interested in this class of annoyance.
Trying every door
A few days earlier, I had wanted Android to turn selected text into a plain PDF. Android already exposed the right seam: the selection menu could hand text to an application I controlled, which could generate the PDF and let Android handle saving it. With Codex doing most of the implementation, I had an installed app in about 25 minutes.
That experience made small, previously unjustifiable pieces of custom software seem more plausible. If implementation becomes cheap enough, an annoyance does not have to grow into a product before it is worth addressing. A small application can exist simply because it makes one recurring interaction fit a little better.
In the same spirit, I casually discussed the current issue with ChatGPT and distilled the conversation down to a Codex prompt to get more into the technical weeds. Codex’s proposed workaround was a DevTools extension side panel that would inspect a response, extract attributes and values, provide search, and add copy buttons.
Fine… it’s a reasonable workaround that I’m sure Codex can hammer out in no time, but as a solution to the original problem, it is quite disproportionate. I had a URL in front of me and wanted to select it without going through the tedious manual motions that, for some reason, I have grown hypersensitive to. The workaround addresses the difficulty of selecting the text by introducing the difficulty of navigating a new interface. This won’t do.
Another path: that Vim “yank inside quotes” command was attractive, so I looked at Vimium as another possibility. But Vimium cannot operate here: its content scripts run in web-page contexts, while DevTools is privileged browser UI rendered in a separate extension-controlled context. Next door.
The only route that gets close is modifying DevTools itself. Chrome DevTools is open source and can be built separately from Chromium, using a custom frontend. Somewhere in that codebase is the response viewer and its selection logic, so the behavioral change might ultimately be quite small, but the surrounding machinery is not: I would need the source tree and build tooling, locate the relevant implementation, maintain a patch against an active project, and launch Chrome with my custom frontend. Updates could break either the patch or the workflow. In practice, I would be maintaining a small piece of infrastructure whose purpose was to spare me from occasionally clicking-and-dragging across a URL.
These boundaries exist for good reasons: security, integrity, and the ability to change internal implementations without preserving every accidental customization surface. From the platform’s perspective, they are sensible constraints. From the user’s perspective, they mean that some tiny pieces of behavior remain effectively fixed.
Giving up (for now)
Software is becoming more malleable, but only within the territory the platform allows us to control. At some point, the proposed AI-assisted workarounds cost more than the annoyance it was meant to remove, and so the old answer then returns: “deal with it.”1
What has changed is that I can see the components of that answer more clearly. “Deal with it” used to bundle together the cost of writing software, learning an unfamiliar platform, setting up the necessary tooling, and maintaining the result. AI removes enough of those costs that the remainder is more visible rather than remaining hidden inside a general sense that customization is not worth the trouble.
In the Android PDF experiment, implementation cost was dominant, and reducing it gave me what I wanted. Here, implementation cost isn’t the issue; the problem is that the platform does not currently expose the relevant extension point.
So for now, I’ll keep clicking and dragging2. Much less satisfying of an ending… maybe more useful as a probe. As software becomes easier to produce and adapt, the more important question may be whether the systems we depend on leave room for people to shape them to their own needs.3
Footnotes
-
There are upstream options: file a feature request, submit feedback, or even patch DevTools itself and propose the change. But that only shifts the cost. Instead of maintaining my own fork, I would be entering Chrome’s contribution and product process and giving up control over whether the behavior is accepted at all. For such a small annoyance, this is still another form of deciding to live with it ↩
-
I may actually prefer copying the entire response into Vim, typing
/textto invoke search, pressingn(next) until I reach the right occurrence, and then usingyi"(or"+yi"to put it directly on the system clipboard). On paper this is considerably more elaborate. In practice it feels less tedious because the sequence is discrete and deterministic: search for this, move to the next match, operate on the text inside these delimiters. Clicking and dragging asks for a different kind of attention, a small amount of continuous visual and motor supervision that I find so irritating (maybe a post for another time). The Vim path also has the useful property that every step is already expressed as an operation rather than a gesture, which makes it an obvious candidate for further automation if I ever repeat it enough for the economics to change. ↩ -
In The Building Block Economy by Mitchell Hashimoto: he argues that AI is especially good at assembling high-quality, well-documented components, and that software designed to be built upon may increasingly have an advantage over software designed only as a finished application. This seems like the positive response to the constraint I ran into here, though it’s at a broader level and doesn’t help with the problem in front of me today. ↩