Can PopClip detect editable fields in browsers?

I have an extension that sends selected text to a rewriting tool. It’s only useful in editable fields, but in browsers and Electron apps, requirements: [paste] and [cut] don’t help — Chromium reports both as available everywhere. The dynamic population function could hide the action, but it’s sandboxed.

Meanwhile, macOS Accessibility does distinguish them:

osascript -e '
  tell application "System Events"
    return value of attribute "AXRole" of \
      (value of attribute "AXFocusedUIElement" of \
      (first application process whose frontmost is true))
  end tell'

Returns AXWebArea for non-editable text, AXTextArea for input fields. Tested in Chrome and Electron apps.

Would it be feasible to expose this as a new requirement (e.g. editable) or add the focused element’s AX role to the context object?

Yes, Chromium has a long-standing issue whereby it enables its Cut and Paste menu items at all times, even when the text selected is not editable. This means PopClip sees all text as editable in Chromium-based browsers.

Currently, PopClip uses the presence of paste and cut as proxy indicators of whether the text is editable.

I’ll check what you say about the web area versus text area. It could be I could use that instead. Could possibly use that as a heuristic to override the cut and paste values.

1 Like