# WebXDC dynamic preview & click listeners (inline apps)

**URL:** <https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647>\
**Category:** Feature Proposal\
**Tags:** webxdc, webxdc-api-future, user-interface\
**Created:** [August 13, 2026, 9:12pm UTC](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647 "2026-08-13T21:12:52Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![ian](https://support.delta.chat/user_avatar/support.delta.chat/ian/32/3164_2.png) [@ian](https://support.delta.chat/u/ian)\
**Post date:** [August 14, 2026, 1:27pm UTC](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647/5 "2026-08-14T13:27:23Z")

</div>

I could think of use cases, but not specifically ones that you have listed. For many use cases, a huge amount of UX redesign would be needed.

If a group chat where people are having conversations also includes chess and a card game attached, it would be a kludge if the player had to open the group and manually scroll back to the “right” position where the game is every time to be able to make their next move. People rather click on the docked app icon next to the subject (on desktop) or select the app from the app drawer panel. Clicking either one will already open the game full screen. Making a tiny icon in the former case interactive would not make sense, and making the still small thumbnail in the latter interactive would still not feel right.

If you wanted to “pin” webxdc messages (subject to further development) so you would not need to scroll back manually, its interface would probably just be a duplicate for what is already available (either the subject xdc icons or the existing app drawer).

If a group has many apps, loading each and every one of them every time you switch to that group or as you scroll the timeline is very resource consuming. Each sandbox consumes quite a bit of memory and a huge CPU load and delay on startup on most platforms.

Even if you only loaded ones you have already interacted with in the past, you probably don’t want the chat to lag due to a concluded poll or finished game that you would not want to open again anyway.

There are quite a lot of other questions you need to answer before you proceed with this.

I mentioned my personal use cases in the other topics for this personally: one would be replacing huge throw-away raster videos with programmable animation that others can realistically fork & improve later. The other is for controlling native webxdc. Additionally, I would value such a feature for previewing unfamiliar webxdc before loading, such as reading through the poll options to decide whether I need to open it or not, but that only works with strict isolation that I have outlined.

> [@Running bots inside deltachat](https://support.delta.chat/t/running-bots-inside-deltachat/3701/5):
>
> Many existing bots and proposals could be ported that are delay-tolerant and need neither Internet access nor relaying everything between a large number of subscribers, such as: moderated forums (PixelSocial, DC-Confluence, DC-Community) multi-player games (Deltaland, others where a game master is needed such as Werewolf, Mafia, Amongus and Among-sus) webxdc gallery (xstore): share apps (and client side bots) with each other Public Bots index: send the contacts and description of all known bot…

> [@Optional Limited Internet Access for WebXDC Apps (Domain Whitelist)](https://support.delta.chat/t/optional-limited-internet-access-for-webxdc-apps-domain-whitelist/5556/8):
>
> One drawback for suggesting as a workaround to visit the original website is if it would incur a huge cost, such as if the webpage and its assets took a lot of time and network bandwidth to load up and could track & fingerprint the user quite a bit. In contrast, it would take orders of magnitudes less bandwidth if a webxdc integration had access to the precise data resource (either from a separate XML, JSON, RSS, Atom or protobuf file or parsed out from the shell HTML) without all the naggers. …

> [@Native "webxdc" app \[transport and identity by groups, restricted RPC, package manager\]](https://support.delta.chat/t/native-webxdc-app-transport-and-identity-by-groups-restricted-rpc-package-manager/5050/3):
>
> The request uses unusual terminology and seems to blur the boundary between at least three things. Could you please share a more concrete scenario for what you would like to use this for? Let me see whether I understand it correctly. You find the webxdc sandbox too constrained and inefficient, hence you would like to implement a game outside the sandbox (or extend an existing native app) and possibly ship it using a native package manager. In this use case, it would be desirable if the given g…

> [@Draft-editing apps \[plugins interacting with your text composer\]](https://support.delta.chat/t/draft-editing-apps-plugins-interacting-with-your-text-composer/4840/9):
>
> How do you plan to add alt text, via local image processing? Also, to support the use case of rich text formatting, the transformation must support changing the type of the output from plain text to HTML, so additional metadata or API would already be involved. I would hope you planned to confirm sending following typo autocorrection also, so that would need some further API or logic. I could also envision slash-like commands in the same box like how certain messengers implement it for common…

---

_[View the full topic](https://support.delta.chat/t/webxdc-dynamic-preview-click-listeners-inline-apps/5647)._
