We observed an intermittent Web Widget Messaging issue involving native Basic
responses, a required category form, and multiple conversations. This channel
does not use an AI Agent or Flow Builder bot.
Zendesk Support asked us to bring the reproduction to the Platform and
Developer community.
Configuration
- Product: Zendesk Messaging Web Widget
- Response type: native Basic response
- AI Agent / Flow Builder: none
- Multiple conversations: enabled
- Authenticated end user through zE("messenger", "loginUser", ...)
- Conversation created either through the native New conversation control
or zE("messenger:ui", "newConversation", ...)
The Basic response sends a required category form with
blockChatInput: true before handing the conversation to Support.
Original failure
The issue reproduced on July 10, 2026:
1. Start a new authenticated conversation.
2. Wait for the native Basic response greeting and required category form.
3. Confirm that the composer is unavailable.
4. Do not answer the form.
5. Refresh the host page once.
6. Reopen the restored conversation.
The unanswered form was restored, but the composer became visible and accepted
free text. This allowed the user to bypass the required category, so the form
response and downstream handoff metadata could be missing.
The network capture made the failure more specific: after refresh, both the
/login response and the restored conversation's /messages response still
contained the form with blockChatInput: true. The server-side value had not
changed; the widget UI did not honor it after restoration.
The failing capture loaded web-widget-main-dc31066.js. The reproduction host
used the standard Zendesk embed and authentication integration, with no parent
page overlay and no code that accessed or modified the Zendesk iframe.
Bare-bones retest
Zendesk Support requested a bare-bones HTML reproduction. On July 15, 2026, we
tested these variants outside our React application:
1. Official Web Widget snippet only, anonymously.
2. Official snippet plus loginUser, using the native New conversation
control.
3. Official snippet plus loginUser, using
messenger:ui newConversation.
The issue no longer reproduced. In both authenticated variants, the category
form remained visible after one refresh and a 15-second wait, while the composer
remained unavailable. The fresh /login and /messages responses still
returned blockChatInput: true, and the widget honored the state.
The non-reproducing capture loaded web-widget-main-631176d.js.
Expected behavior
When an unanswered native form has blockChatInput: true, the composer should
remain unavailable after conversation restoration until the form is submitted
or a later business message intentionally clears the block.
The blocked state must also remain scoped to its conversation: switching to an
older completed conversation should not inherit the block, and switching back
to a new conversation with an unanswered form should restore it.
Questions
1. Was a Web Widget Messaging change deployed between
web-widget-main-dc31066.js and web-widget-main-631176d.js that affected
restoration of blockChatInput after a host-page refresh?
2. Is honoring blockChatInput: true after restoration part of the supported
lifecycle for native Basic response forms with multiple conversations?
3. Is there a supported event or API that lets an embedding application verify
whether the active conversation is blocked by a native form, without
inspecting or covering the Zendesk iframe?
4. If the original behavior was a defect that has since been fixed, can
Zendesk confirm the fix or release so we can keep an appropriate regression
test?
We can provide the sanitized HAR, recordings, screenshots, exact bare-bones
HTML pages, and network assertions through a private Zendesk-approved channel.