JupyterLab Front End and a Custom Kernel: What Does the Messaging Protocol Actually Guarantee for Rich Output?

Direct answer

The Jupyter messaging protocol does not guarantee a specific MIME-type priority for display_data, nor does it dictate how widget state is synchronized. Those decisions are left to the front end. A minimal kernel that works with both JupyterLab and the classic Notebook must implement the core request/reply pairs for kernel info, execution, and shutdown. Widget-related comm_* messages, inspection, completion, and completeness checks are widely expected but not strictly required for basic execution. When the front end advertises an older protocol version than the kernel supports, the kernel should restrict itself to the features defined by the version it advertises in kernel_info_reply and avoid using newer message types or fields.

Confirmed facts (from the protocol spec)

• The envelope (header, parent_header, metadata, content) and the four channels (shell, stdin, control, IOPub) are fully defined.
• display_data and update_display_data carry a MIME-bundle (a mapping of MIME type to data). The spec does not define an ordering or fallback rule.
• A kernel must reply to kernel_info_request with protocol_version, implementation, implementation_version, and banner.
• For basic execution the kernel must send on IOPub: status (busy/idle), stream, error, and display_data (or update_display_data) as appropriate.
• shutdown_request must be answered with shutdown_reply.

Likely explanation (front-end policy)

JupyterLab and the classic Notebook each maintain their own MIME-type preference lists (e.g., JupyterLab favours application/vnd.jupyter.widget-view+json then text/html then image/svg+xml then image/png then text/plain; the classic Notebook uses a different ordering). Because the protocol does not enforce priority, the same display_data payload can render differently in the two front ends. Widget state synchronization uses the comm_open, comm_msg, and comm_close messages on IOPub and shell; whether those messages are acted upon depends on the presence of a widget manager extension in the front end, which is not guaranteed by the wire contract. If no widget manager is present, comm traffic is silently ignored.

Steps to verify your kernel's behaviour

1. Check the kernel_info_reply your kernel sends: confirm the protocol_version field matches the oldest version you intend to support.
2. Send a display_data message containing identical content for text/plain, text/html, and image/png. Observe which representation each front end renders; this reveals the front end's priority list.
3. Emit a comm_open with a custom target ID and a subsequent comm_msg. Verify whether JupyterLab's widget manager processes the message while the classic Notebook ignores it (or vice versa) to confirm comm handling depends on front-end extensions.
4. To test version handling, temporarily force your kernel to advertise an older protocol_version (e.g., 5.3) and ensure you do not send any message types or fields introduced after that version. Then run the kernel with a front end that knows only that older version; no protocol errors should appear.

Missing diagnostic detail

If you are unsure what protocol_version your kernel currently advertises in kernel_info_reply, please provide that value. Knowing the exact version determines whether you need to restrict usage of newer features (e.g., fields added after protocol 5.3) to maintain compatibility.