| BB-009 |
New |
ChatComposer / ChatComposerDrawer playground scaffolding |
Chat Composer Drawer playground does not look right when rendered standalone; it likely needs to be composed inside XDSChatComposer or another component-specific scaffold so the drawer is visible in its intended context. Chat Composer playground is also squished by default and likely needs an explicit playground-only width/container. Expected: Chat subcomponent playgrounds should render in realistic composer/chat scaffolds or use preview container defaults so component geometry matches real usage. |
No separate duplicate found; related to #2008 for playground defaults/slotElements, but this is broader because defaults alone may not express wrapper/scaffold/container requirements. |
C11 — Component-specific playground scaffolds/container constraints; also C2. Fix candidates: extend playground config to support wrapper/scaffold or preview container sizing, and add Chat-specific scaffolds/default widths for ChatComposer and ChatComposerDrawer. |
| BB-008 |
New |
ChatComposerDrawer / With Progress example |
ChatComposerDrawer — With Progress should hide the progress bar label in the example. Expected: the progress indicator should not show an extra visible label/value label if it creates clutter or duplicates surrounding context; keep an accessible label only. Code signal: ChatComposerDrawerWithProgress.tsx uses XDSProgressBar value={42} label="Context usage" isLabelHidden hasValueLabel; verify whether hasValueLabel or generated docsite output is still surfacing visible label text. |
No duplicate issue found for ChatComposerDrawer / With Progress / ProgressBar label. |
C10 — Chat example composition polish. Likely fix is in the block example source, e.g. hide/remove visible value label while preserving accessibility. |
| BB-007 |
New |
ChatComposer / ChatComposerDrawer docsite docs content |
Chat Composer and Chat Composer Drawer pages on the docsite are showing Chat Message List docs/usage content instead of component-specific docs. Expected: /components/ChatComposer should describe composer behavior and slots (drawer/header/input/footer/send/status), and /components/ChatComposerDrawer should describe drawer/collapse/count/attachment behavior — neither should inherit message-list composition guidance. Likely root cause: extracted Chat subcomponent docs such as ChatComposer.doc.mjs and ChatComposerDrawer.doc.mjs have subComponentOf: 'Chat' but no own usage block, so generate-data.mjs falls back to the parent Chat.doc.mjs usage; the parent Chat usage is currently MessageList-focused. |
No duplicate issue found for ChatComposer/ChatComposerDrawer showing ChatMessageList docs. |
C9 — Subcomponent docs inherit mismatched parent usage. Fix candidates: create separate usage docs for each Chat subcomponent and/or make generated docs avoid inheriting parent usage for extracted subcomponents unless explicitly requested. |
| BB-005 |
New |
ClickableCard / SelectableCard example titles |
Template examples ClickableCardWithNestedButton and SelectableCardMulti do not follow the standard example title convention, so their docsite titles look malformed (Clickable Card With Nested Button, Selectable Card Multi). Expected: title metadata should use the standard component example pattern, e.g. component name plus a readable variant label (Clickable Card — Nested Button, Selectable Card — Multi-select) rather than leaking PascalCase/export-name wording. |
No duplicate issue found for these example names/titles. |
C8 — Template/example metadata naming conventions. Likely fix is in the .doc.mjs block metadata (displayName/possibly name) and perhaps a lint/check so future generated example titles follow the convention. |
| BB-006 |
New |
ClickableCard / SelectableCard docsite playgrounds |
ClickableCard and SelectableCard playgrounds need better default content. Current generated playground state is too empty because these card docs have no playground.defaults and children is optional/no slot default, so the previews do not demonstrate meaningful card layouts. Expected: default content should include useful card body copy/heading and realistic control setup (label + href/onClick for ClickableCard; label + selected/onChange state for SelectableCard). |
Related to broad tracking issue #2008 (Add playground defaults and slotElements to all component docs); this row captures the specific ClickableCard/SelectableCard acceptance criteria. |
C2 — Preview harness state/control/default wiring. Add playground.defaults and/or children slot defaults in ClickableCard.doc.mjs and SelectableCard.doc.mjs. |
| BB-003 |
New |
Toolbar / Table Toolbar example |
Toolbar → Composition: Table Toolbar (docsite/story example) uses plain secondary buttons labeled Status, Priority, and Assignee as if they were filter dropdowns/selectors. Expected: use actual selector/dropdown/menu controls for filter values (or make them honest action buttons) so the example teaches the right composition pattern. |
No direct duplicate found for Toolbar/Table Filter; loosely related to #2870, another Toolbar example cleanup. |
C7 — Toolbar docs/example fidelity. The example is semantically misleading: buttons are standing in for selection/filter controls. |
| BB-004 |
New |
Toolbar / docsite playground |
Toolbar playground starts too empty and does not offer useful Toolbar-specific slot content. startContent, centerContent, and endContent should have richer slot options across the slots: text, button, icon button, tab list, and segmented control (and likely selector/dropdown patterns where relevant). Expected: meaningful playground defaults plus slot controls that let users explore realistic toolbar compositions. |
Related to broad tracking issue #2008 (Add playground defaults and slotElements to all component docs), which explicitly lists Toolbar as medium priority; this row captures the specific Toolbar acceptance criteria. |
C2 + C7 — preview defaults/slot modeling and Toolbar docs fidelity. Current Toolbar.doc.mjs slotElements are narrow (XDSIcon/XDSText/XDSBadge) and there is no Toolbar-specific playground.defaults. |
| BB-002 |
New |
Timestamp / docsite playground |
Timestamp component page playground renders Render error: Invalid time value on load. Expected: the playground should use a valid timestamp default so the component renders immediately. Likely repro path: generated playground initial state treats required value: string | number as a generic string/number control without a semantic default; getRequiredFallbackValue currently falls back to the prop name ("value") for required strings, and XDSTimestamp calls date.toISOString() on new Date("value"), throwing Invalid time value. |
No duplicate issue found in GitHub issue search for Timestamp / invalid time / render error. |
C2 — Preview harness state/control/default wiring. Fix candidates: add playground.defaults.value to Timestamp.doc.mjs (e.g. ISO string or Unix seconds) and/or make docsite required fallback smarter for date/time prop names; consider component-level invalid-date guard if invalid consumer input should not crash docs. |
| BB-001 |
New |
Thumbnail / demo media |
XDSThumbnail isLoading/upload examples are hard to evaluate: the no-src skeleton is very low-visibility, and the image-backed overlay/remove-button contrast path does not work in hosted examples because useImageMode fetches the demo image for APCA sampling and https://lookaside.facebook.com/assets/xds_oss/moody-scene-vertical-2.png is blocked by CORS from https://xds-sandbox.vercel.app (No Access-Control-Allow-Origin). Expected: loading states are visibly distinct and media-theme/APCA contrast works in docs/examples without console CORS failures. Repro: Thumbnail examples using lookaside assets on the sandbox/docsite. |
No duplicate issue found in GitHub issue search for Thumbnail/isLoading/APCA/lookaside/CORS. |
C6 — Cross-origin demo media breaks runtime image analysis. Possible strategy shift: use self-hosted/CORS-enabled fixture assets or avoid fetch/canvas pixel sampling for public demo URLs; separately check whether the skeleton token contrast should be strengthened. |
Bug bash tracker
Use this issue as the rolling tracker for the current manual bug bash. As new findings come in, keep the list deduplicated and update the suspected root-cause clusters so we can see when one fix may close multiple reports.
Operating rules
Current reports from this thread
XDSChatComposeror another component-specific scaffold so the drawer is visible in its intended context. Chat Composer playground is also squished by default and likely needs an explicit playground-only width/container. Expected: Chat subcomponent playgrounds should render in realistic composer/chat scaffolds or use preview container defaults so component geometry matches real usage.playgroundconfig to support wrapper/scaffold or preview container sizing, and add Chat-specific scaffolds/default widths forChatComposerandChatComposerDrawer.ChatComposerDrawer — With Progressshould hide the progress bar label in the example. Expected: the progress indicator should not show an extra visible label/value label if it creates clutter or duplicates surrounding context; keep an accessible label only. Code signal:ChatComposerDrawerWithProgress.tsxusesXDSProgressBar value={42} label="Context usage" isLabelHidden hasValueLabel; verify whetherhasValueLabelor generated docsite output is still surfacing visible label text./components/ChatComposershould describe composer behavior and slots (drawer/header/input/footer/send/status), and/components/ChatComposerDrawershould describe drawer/collapse/count/attachment behavior — neither should inherit message-list composition guidance. Likely root cause: extracted Chat subcomponent docs such asChatComposer.doc.mjsandChatComposerDrawer.doc.mjshavesubComponentOf: 'Chat'but no ownusageblock, sogenerate-data.mjsfalls back to the parentChat.doc.mjsusage; the parent Chat usage is currently MessageList-focused.usagedocs for each Chat subcomponent and/or make generated docs avoid inheriting parent usage for extracted subcomponents unless explicitly requested.ClickableCardWithNestedButtonandSelectableCardMultido not follow the standard example title convention, so their docsite titles look malformed (Clickable Card With Nested Button,Selectable Card Multi). Expected: title metadata should use the standard component example pattern, e.g. component name plus a readable variant label (Clickable Card — Nested Button,Selectable Card — Multi-select) rather than leaking PascalCase/export-name wording..doc.mjsblock metadata (displayName/possiblyname) and perhaps a lint/check so future generated example titles follow the convention.ClickableCardandSelectableCardplaygrounds need better default content. Current generated playground state is too empty because these card docs have noplayground.defaultsandchildrenis optional/no slot default, so the previews do not demonstrate meaningful card layouts. Expected: default content should include useful card body copy/heading and realistic control setup (label+href/onClickfor ClickableCard;label+ selected/onChange state for SelectableCard).Add playground defaults and slotElements to all component docs); this row captures the specific ClickableCard/SelectableCard acceptance criteria.playground.defaultsand/orchildrenslot defaults inClickableCard.doc.mjsandSelectableCard.doc.mjs.Toolbar→Composition: Table Toolbar(docsite/story example) uses plain secondary buttons labeledStatus,Priority, andAssigneeas if they were filter dropdowns/selectors. Expected: use actual selector/dropdown/menu controls for filter values (or make them honest action buttons) so the example teaches the right composition pattern.Toolbarplayground starts too empty and does not offer useful Toolbar-specific slot content.startContent,centerContent, andendContentshould have richer slot options across the slots: text, button, icon button, tab list, and segmented control (and likely selector/dropdown patterns where relevant). Expected: meaningful playground defaults plus slot controls that let users explore realistic toolbar compositions.Add playground defaults and slotElements to all component docs), which explicitly lists Toolbar as medium priority; this row captures the specific Toolbar acceptance criteria.Toolbar.doc.mjsslotElements are narrow (XDSIcon/XDSText/XDSBadge) and there is no Toolbar-specificplayground.defaults.Render error: Invalid time valueon load. Expected: the playground should use a valid timestamp default so the component renders immediately. Likely repro path: generated playground initial state treats requiredvalue: string | numberas a generic string/number control without a semantic default;getRequiredFallbackValuecurrently falls back to the prop name ("value") for required strings, andXDSTimestampcallsdate.toISOString()onnew Date("value"), throwingInvalid time value.playground.defaults.valuetoTimestamp.doc.mjs(e.g. ISO string or Unix seconds) and/or make docsite required fallback smarter for date/time prop names; consider component-level invalid-date guard if invalid consumer input should not crash docs.XDSThumbnailisLoading/upload examples are hard to evaluate: the no-src skeleton is very low-visibility, and the image-backed overlay/remove-button contrast path does not work in hosted examples becauseuseImageModefetches the demo image for APCA sampling andhttps://lookaside.facebook.com/assets/xds_oss/moody-scene-vertical-2.pngis blocked by CORS fromhttps://xds-sandbox.vercel.app(No Access-Control-Allow-Origin). Expected: loading states are visibly distinct and media-theme/APCA contrast works in docs/examples without console CORS failures. Repro: Thumbnail examples using lookaside assets on the sandbox/docsite.Suspected root-cause clusters
Seeded from currently open
bug-bashissue titles; refine as we investigate new reports.lookaside.facebook.comimage URLs that can render in<img>but cannot be fetched with CORS for pixel sampling, souseImageMode/APCA-backed media theming fails silently and overlay contrast becomes unreliable. The CLI already strips lookaside URLs for scaffolded templates, but docsite/block examples still reference them directly.startContent/centerContent/endContentplayground options realistic.displayNamevalues should follow a readable docs convention and not leak PascalCase/export-name wording. A small metadata cleanup or lint could prevent malformed example titles across component docs.usageinherit the parent family usage ingenerate-data.mjs; this can leak docs for a different component into the subcomponent detail page. Chat likely needs separate usage docs per subcomponent rather than inheriting the MessageList-focused family usage.Update log
Invalid time value; no duplicate issue found; consolidated under C2 as a preview initial-default/control issue.XDSThumbnailloading visibility + lookaside CORS blocking APCA/useImageMode; no duplicate issue found; added C6 root-cause cluster for cross-origin demo media/canvas sampling.Maintained by Navi on behalf of @cixzhang during bug bash.