Extend ZObject copy/paste so it works across Abstract Wikipedia and Wikifunctions
Open, MediumPublicFeature

Description

Feature summary (what you would like to be able to do and where):

Copy a ZObject fragment from the WikiLambda editor’s context menu (Abstract Wikipedia content or Wikifunctions objects) and paste it into the editor on the other wiki—the same “copy / paste from clipboard” flows users already have per site, but working across *.wikipedia.org (Abstract Wikipedia) and Wikifunctions, without relying on browser localstorage that is tied to a single origin.


Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

  1. Edit on Wikifunctions and use Copy to clipboard from the 3 dot menu for a fragment you want to reuse.
  2. Open (or switch to) an Abstract Wikipedia page and open the fragment menu (or the reverse: copy on Abstract Wikipedia, paste on Wikifunctions).
  3. Use Paste from clipboard (or open the clipboard dialog) and expect to see the item you copied.

What happens today:
the in-app clipboard is backed by mw.storage / local storage for the key ext-wikilambda-app-clipboard, which is scoped per origin. The storage event only syncs across tabs on the same site, not across Abstract Wikipedia and Wikifunctions. So the pasted wiki has no record of what the other wiki stored.

Underlying problem:
authors who work across both products cannot reuse structured fragments via the existing clipboard UI; they are forced to retyping/duplicating work.


Benefits (why should this be implemented?):

  • Smoother cross-product authoring: Reuse implementations, types, and abstract fragments between Wikifunctions and Abstract Wikipedia with the same mental model as same-wiki copy/paste.
  • Less friction and fewer errors: Fewer manual JSON edits or re-building of the same structure on the second wiki.
  • Aligns with user expectations: “Clipboard” in a multi-wiki setup is commonly assumed to work like the system clipboard when moving between sites.
  • Supports real workflows where function wiring and abstract content are edited on different hosts during the same session.

Technical context (optional extension):

Cross-origin sharing cannot use localStorage / mw.storage alone; bridging wikis requires the system clipboard (or another explicit user-mediated channel) plus a defined wire format (e.g. JSON) and the same paste cleaning / ZID resolution behavior on the destination. Implementation should respect clipboard read permission and user-gesture rules, and handle validation and size limits safely (Very large JSON may hit OS/browser limits; cap size or truncate with a warning. ).

Event Timeline

Jdforrester-WMF subscribed.

Note that we cannot programmatically ever read from the system clipboard (browser security model), so we can't use that, and we cannot store private content on the servers, per Legal, so this may be tough to come up with a fix.

Modern browsers DO allow programmatic clipboard access, but with strict rules:

Writing (copy) → generally allowed

You can programmatically copy to clipboard:

await navigator.clipboard.writeText(jsonString);

Requirements:

  • Must be triggered by a user gesture (click, keypress)
  • Must be in a secure context (HTTPS)

Reading (paste) → restricted but NOT impossible

You can read from clipboard:

const text = await navigator.clipboard.readText();

BUT:

  • Must be triggered by a user gesture
  • Often requires explicit permission prompt
  • Some browsers block or limit it (especially older Safari)
  • Can fail silently or throw

Idea could also be:

[ Copy JSON ]  → writes to clipboard

Destination:

[ Paste from clipboard ] (try programmatic read)
[ Or paste manually ] (textarea fallback)

But yeah we should research all limitations for our use case or come up with something else (dont know what else yet haha)