Docs › Reference

Known limits

What Notato does not do yet, and what has not been tried.

Known limits#

• Screenshots are a DOM re-render, so canvas, cross-origin images, video and some fonts may be missing, and position: sticky elements are not placed where they were. A driver can supply real pixels instead (screenshot above).

• Without the Vite plugin, source locations come from React development builds and are best effort; in a built app they are the component name only.

• Notato keeps the mouse, touch and focus events of its own toolbar and popover from bubbling out to the page, so a modal or menu that closes on a click outside it (a mousedown or click listener on document) stays open while you annotate it. A page that listens for that in the capture phase on document runs before Notato can stop it and will still close.

• A disabled control inside someone else's shadow root cannot be picked, because the browser drops its events before any script sees them; annotate its container instead.

• Computed styles are a fixed set of about twenty-five properties, not everything the browser knows, and they are read when the note is made, not live.

• Pause cannot stop animation that JavaScript drives frame by frame. A cross-origin iframe is one element, with nothing inside it (see above).

• Variants work on markers in the page's own document and same-origin iframes, not inside shadow roots, and every version is rendered (just hidden), so a version that makes requests when it mounts will make them. The agent writes the versions: Notato does not generate or diff code.

• The extension has been exercised against a real server with only the browser's own extension APIs stood in for; it has not yet been tried loaded into Chrome itself.

• How much it holds. A server with tens of thousands of notes stays quick: lists are paged and indexed, a project's notes page through in tens of milliseconds, and an agent's watch asks an index rather than reading every note. Limits keep any one thing from swamping the rest:

  • a note takes at most 1,000 replies (an agent can still close it with a note); a reply or a comment is at most 10,000 characters, a note's context at most 512 kB, and a whole note with its screenshots at most 25 MB;
  • notato_watch hands each reply over once (a new agent session is not handed old ones again), at most twenty a call, and notato_get writes out a thread's latest twenty replies;
  • a bundle zip is at most 100 MB with 20,000 files, and an export of any size streams a screenshot at a time;
  • an app's list can ask for ?fields=summary, which leaves each note's context (console, network, styles) and steps out;
  • a webhook that is down keeps at most 1,000 deliveries waiting, and deleting a whole project sends none.

  The board draws a project's list two hundred notes at a time. There is no rate limit on writes yet.

• Webhooks are configured on the server, not from a page, and delivery is in memory: a restart drops anything still being retried. reopened is told from updated by remembering each annotation's last status, so right after a restart the first change to an annotation is reported as updated.

• Notato has been exercised in Chromium. Safari and Firefox have not been tried, and Safari in particular treats some of what the picker relies on (events on disabled controls, shadow DOM hit testing) differently.

• Not built yet: layout mode (rearranging elements and sending the rectangle), source-location loaders for Webpack and Turbopack (the Vite plugin is the only one, and without it Next.js apps get component names and selectors), real-time presence (who is on the page now, live cursors), and server accounts with roles.

• Out of scope for now: session replay, analytics, heatmaps, SSO, Postgres. Each mobile SDK lists its own limits in its README.