CopilotChat message wrappers used viewport-keyed `cpk:sm:px-0`, collapsing
horizontal padding to 0 at any viewport >=640px. The message column is
`max-w-3xl` (768px) centered; the design assumes the chat fills the viewport,
so at >=640px the column has side gutters and inner padding can drop to 0.
But when the chat lives in a sub-viewport-width pane (e.g. the threads drawer
rail beside the chat, ~580px on an 820px iPad-portrait viewport), `sm:px-0`
still fires on viewport width while the 768px column overflows the narrow
pane and sits flush against both edges. The input wrapper looked fine because
it is visually inset by its own pill, so only message text appeared broken.
Make the padding container-relative instead of viewport-relative:
- add `cpk:@container` (container-type: inline-size) to the chat root, and
- switch the message/input/suggestion wrappers from `cpk:sm:px-0` to the
container variant `cpk:@3xl:px-0`.
Padding now tracks the chat's own width and drops to 0 only once the container
is at least as wide as the column's own max-width, so the column has real
gutters; in any narrower pane the `px-4` inner padding is retained. React,
Angular, and Vue kept in lockstep.
Note on the breakpoint: Tailwind v4 container-query breakpoints differ from
viewport breakpoints (`@sm` = 24rem/384px, not 640px). A mechanical
`sm:` -> `@sm:` swap would still collapse the ~580px repro pane. `@3xl`
(48rem/768px) is used because it exactly matches the column's `max-w-3xl`,
which is the width at which side gutters first appear.
Verified: full-width desktop chat unchanged (container >=768px -> px-0);
580px pane retains 16px padding; render-prop layouts without a container
ancestor degrade safely to `px-4`; sidebar/popup `data-*` padding overrides
are unaffected.
ENT-1020
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
### What
The Angular `CopilotChatInput.handleKeyDown` submits the message when
Enter is pressed without Shift, but it never checks whether an IME
composition is in progress. When typing CJK text (Japanese, Chinese,
Korean), the Enter that confirms an IME candidate also fires a
`keydown`, so the half-composed text gets sent instead of the candidate
being committed.
The React and Vue bindings of the same v2 `CopilotChatInput` already
guard against this; Angular was the one binding still missing it:
- `packages/react-core/src/v2/components/chat/CopilotChatInput.tsx` —
`handleKeyDown` returns early on `e.nativeEvent.isComposing || e.keyCode
=== 229`
- `packages/vue/src/v2/components/chat/CopilotChatInput.vue` —
`handleKeydown` returns early on `isComposing.value || event.isComposing
|| event.keyCode === 229`, and has a test asserting it does not submit
while composing
### Change
Add the same early return to the Angular `handleKeyDown`, using the
native `KeyboardEvent` (`event.isComposing || event.keyCode === 229`),
which matches the Vue binding's idiom.
### Notes
When composition is not active `isComposing` is `false`, so Enter
submits exactly as before and Shift+Enter still inserts a newline. The
most visible case is Safari with a Japanese IME, where the confirming
Enter reports `key === "Enter"` with `isComposing === true`; the
`keyCode === 229` arm mirrors the sibling guards for browsers that
report the composing key that way.
I verified the handler logic in isolation (Enter while composing no
longer submits; plain Enter and Shift+Enter are unchanged). I did not
run the full Angular suite locally.
A2UI's catalog-on-provider path needs a catalog to pass to
`a2ui.catalog`, but the library build tree-shook the nested barrel
re-export so vueBasicCatalog was unreachable at runtime (present only in
the .d.ts). Re-export it explicitly from the v2 entry, mirroring React's
`basicCatalog` export from @copilotkit/a2ui-renderer. Add an export test
guarding against the regression.
The Vue CopilotKitProvider gated all A2UI activation on the runtime
signal (core.a2uiEnabled), so passing an a2ui.catalog to the provider
did nothing: surfaces never rendered locally and the runtime was never
told to inject the render tool. React already supports the
catalog-on-provider path (1.61.2).
Mirror React: a provided catalog now activates A2UI locally and forwards
the a2uiCatalogAvailable property so the runtime injects the render tool
without a runtime-side a2ui config. User-provided properties are
preserved alongside the signal.
Fixes#5774
Three snapshot tests (lines 751/771/789) call test() while the file uses
explicit vitest named imports. They pass at runtime via vitest's global
but fail tsc check-types (TS2593). Add test to the import.
Memory, NewMemory, MemoryChanges, MemoryKind, and MemoryScope are the
memory types surfaced by the useMemories / injectMemories hook result
shapes, so export them unprefixed as supported public API instead of
behind the ɵ "internal" marker. Internal memory plumbing (MemoryStore,
the selectMemories* selectors, state/context/event types,
createMemoryStore) keeps the ɵ prefix.
Updates the react-core and angular hook signatures, the web-inspector
Memories tab, and the affected tests to the unprefixed names.
The opts parameter (not just its fields) must be optional so consumers can
write createBot({ adapters: [intelligenceAdapter()] }). Add a zero-arg
regression test.
Make source/egress optional on intelligenceAdapter(); when omitted it builds
default HTTP transports that talk to a running Intelligence app-api
(heartbeat/claim/lease-fenced ack-fail + idempotent egress), resolved from env
(COPILOTKIT_INTELLIGENCE_URL/COPILOTKIT_API_KEY) and the bot's name. Consumers
now write createBot({ adapters: [intelligenceAdapter()] }).
- http-transports.ts: HttpDeliverySource, HttpEgressSink, resolveTransportConfig
- ir-to-text.ts: flatten BotNode[] -> plain text for the egress first slice
- bot core: PlatformAdapter.start(sink, ctx?) carries botName from createBot
(additive, backwards-compatible); export transports as undocumented fallbacks
- tests: bot-intelligence 36 green, bot 150 green
Relates to OSS-360, OSS-361, OSS-363.
- Revert the v2 useRenderToolCall fallback: when no per-tool or wildcard renderer is
registered, return null instead of auto-painting DefaultToolCallRenderer. Showing the
card is opt-in via useDefaultRenderTool().
- The auto-card default shipped silently in v1.57.2 (commit ba60df5d33, buried in a
showcase per-tool-testids commit, no CHANGELOG entry) and leaked internal tool names +
raw args/result JSON (e.g. generate_a2ui) into every v2 app's chat in production.
- Remove the now-dead defaultToolCallRenderAdapter + __testOnly_ export + unused imports.
- Rewrite the resolver test to assert the 3-state opt-in contract: useDefaultRenderTool()
-> card, useDefaultRenderTool({render}) -> custom, no hook -> nothing.
The Angular CopilotChatInput sends the message on Enter without checking
for IME composition, so confirming a CJK candidate with Enter submits the
half-composed text. The React (react-core v2) and Vue (vue v2) bindings of
the same CopilotChatInput already guard this with isComposing/keyCode 229.
Add three flat test cases verifying the silent-degrade contract:
404/501 list response sets available:false with no error; 500 response
sets error and keeps available:true; 404 subscribe response is silent
with no console.warn emitted.
Benjamin Taylor