Here's how DeskRamp's e-Sign feature actually works, entirely client-side, no server involved.

Step one: capture the signature

The drawing surface is a plain HTML <canvas>, tracking pointer events to build a path:

canvas.addEventListener('pointermove', (e) => {
  if (!isDrawing) return;
  ctx.lineTo(e.offsetX, e.offsetY);
  ctx.stroke();
});

Once the user's done, the canvas exports as a PNG via canvas.toBlob() — this part is unremarkable, it's the same pattern every signature-pad library uses.

Step two: the coordinate system mismatch

This is the part that isn't obvious until it bites you. Canvas coordinates start at the top-left: (0, 0) is the top-left corner, and Y increases downward. PDF page coordinates start at the bottom-left: (0, 0) is the bottom-left corner, and Y increases upward.

If you take the canvas coordinates where a user placed their signature and hand them directly to a PDF library's drawImage(x, y) call, the signature lands in the mirror-image vertical position — a signature placed near the bottom of the visible page ends up drawn near the top of the actual PDF page. Nothing throws an error. It just silently looks wrong, which is worse than a crash because it's easy to miss in a quick test with a signature placed near the vertical center, where the visual difference is smaller.

The fix is a straightforward flip, but you have to remember to do it:

const pdfY = pageHeight - canvasY - signatureHeight;

pageHeight comes from the actual PDF page's dimensions (page.getHeight() in pdf-lib), not the canvas's — the canvas is just a UI surface at whatever CSS size it's rendered, while the PDF page has its own coordinate space in points, and the two aren't the same scale either. Both the flip and the scale factor have to account for the ratio between the canvas's pixel dimensions and the PDF page's point dimensions, or the signature places correctly on one but drifts on the other as page sizes vary.

Step three: embedding, not just drawing

The signature PNG gets embedded as an actual image object in the PDF, not composited onto a rasterized version of the page:

const pngImage = await pdfDoc.embedPng(signatureBytes);
page.drawImage(pngImage, {
  x: placementX,
  y: pdfY,
  width: scaledWidth,
  height: scaledHeight,
});

This matters for output quality — embedding preserves the rest of the page as real vector/text content instead of flattening the whole document into an image, which is what you'd get if you rendered the PDF to a canvas, drew the signature on top, and re-exported the canvas as a new PDF. That approach is simpler to reason about but produces a much larger file and loses text selectability on every page, not just the signed one.

Why none of this needs a server

Every step here — canvas capture, the coordinate math, the embed call — runs on data that's already local: the PDF file the user opened, and the signature they just drew. There's no reason any of it needs to leave the browser tab, which is the same principle behind the rest of DeskRamp's toolkit. The signature workflow just makes the "why local processing is enough" case more concretely, since a signature is about as sensitive a thing to hand to a third-party server as a document gets.

DeskRamp is free on the Chrome Web Store.

I ran into exactly this while building the feed-hiding logic for FocusRamp, a Chrome extension that hides distracting social feeds instead of blocking entire sites. The bug took a while to track down, and the fix ended up reshaping how every DOM-dependent feature in the extension is built.

The setup

Feed-hiding sounds simple on paper: find the feed's wrapper element, toggle its display style, done. Something like:

const feedWrapper = document.querySelector('[role="feed"]');
if (feedWrapper) feedWrapper.style.display = 'none';

Cache that reference once, toggle it whenever the user flips focus mode on or off. Works great in testing. Then, after toggling an unrelated feature (in my case, a dark-mode-style CSS filter), the feed would silently reappear — and toggling focus mode again wouldn't hide it back.

The actual bug: your reference goes stale

The root cause wasn't the toggle logic at all. It was that Facebook's feed is virtualized — the actual DOM node behind that [role="feed"] selector gets unmounted and remounted whenever the page repaints in certain ways (in my case, triggered by the CSS filter change). Your cached feedWrapper variable still points to a real DOM node — it just isn't the one on the page anymore. Setting .style.display = 'none' on it does nothing visible, because the visible element is a different node that happens to match the same selector.

This is easy to miss because nothing throws. feedWrapper.style.display = 'none' on a detached node is completely valid JavaScript — it just has no effect on what the user sees.

The fix: stop trusting references, re-verify instead

The fix isn't a smarter selector — no selector survives a full remount. The fix is to stop caching a single reference at all, and instead treat every mutation-observer tick as an opportunity to re-verify state against whatever's actually on the page right now:

const hiddenWrappers = new Map(); // wrapper -> previous display value

function applyFeedState(shouldHide) {
  const wrapper = document.querySelector('[role="feed"]');
  if (!wrapper) return;

  if (shouldHide && !hiddenWrappers.has(wrapper)) {
    hiddenWrappers.set(wrapper, wrapper.style.display);
    wrapper.style.display = 'none';
  } else if (!shouldHide && hiddenWrappers.has(wrapper)) {
    wrapper.style.display = hiddenWrappers.get(wrapper);
    hiddenWrappers.delete(wrapper);
  }
}

new MutationObserver(() => applyFeedState(currentFocusModeState))
  .observe(document.body, { childList: true, subtree: true });

The Map keyed by wrapper element means the code self-heals: if the page swaps in a new wrapper node, the next mutation-observer tick re-queries, finds the new node, and applies state to it — no stale reference, nothing to go silently out of sync. The old wrapper, if it's still floating around detached, is simply irrelevant; nothing holds a reference to it anymore.

Why this pattern generalizes

This isn't specific to feed-hiding — it's the shape of every bug you'll hit injecting into a page you don't control. Any extension feature built on "find the element once, remember it, act on it later" has an implicit assumption baked in: that the element you found is the element that'll still be there. On a static page, that assumption mostly holds. On a modern SPA — and nearly every major site is one now — it doesn't, and the failure mode is always the same: no error, no crash, the feature just quietly stops doing anything.

The reliable pattern is re-verification, not memoization: query fresh on every relevant tick, and use a Map (or WeakMap, if you don't need to enumerate keys) if you need to track per-element state across those re-queries rather than a single top-level variable. It costs a little more CPU than caching once, but a querySelector call is cheap, and "slightly more CPU" beats "silently broken" every time.

If you're building anything that hooks into a site you don't control, it's worth assuming from day one that every DOM reference you hold has an expiration date you can't predict — and designing for that instead of discovering it the hard way.

If you're curious what this looks like in a shipped product: FocusRamp is free on the Chrome Web Store.