fix(content-controls): default newly-created controls to richText, not unknown (SD-3139)#3281
Merged
Merged
Conversation
…t unknown (SD-3139) Follow-up to SD-3131 (#3275). After that PR, imported typeless w:sdtPr correctly resolves to controlType: 'richText' per ECMA-376 §17.5.2.26, but newly created controls via create.contentControl (no controlType) and contentControls.wrap still defaulted to 'unknown'. Customers filtering contentControls.list() by type saw different results before vs after save/reopen — the same typeless OOXML round-tripped from 'unknown' to 'richText'. - createWrapper: collapse three `?? 'unknown'` into a single `?? 'richText'` local. - wrapWrapper: explicitly seed controlType, type, and a default sdtPr with <w:richText/> on the wrapper attrs (previously controlType was unset entirely, leaving resolveControlType to fall back to 'unknown'). Newly created controls now emit explicit <w:richText/> in sdtPr for unambiguous engine state and exported markup. Imported typeless Word-authored SDTs preserve their original raw sdtPr (import path unchanged). Per the SD-3131 design, 'unknown' keeps its meaning of "unsupported or unrecognized type" — it's no longer the default for new controls. Tests: 3 new (default-create → richText, explicit-richText-create seeds <w:richText/>, wrap → richText + seeds <w:richText/>). 42 wrappers + 1189 conformance + 1398 document-api pass.
Contributor
|
🎉 This PR is included in @superdoc-dev/mcp v0.3.0-next.90 The release is available on GitHub release |
Contributor
|
🎉 This PR is included in vscode-ext v2.3.0-next.135 |
Contributor
|
🎉 This PR is included in @superdoc-dev/react v1.2.0-next.133 The release is available on GitHub release |
Contributor
|
🎉 This PR is included in superdoc-cli v0.8.0-next.105 The release is available on GitHub release |
Contributor
|
🎉 This PR is included in superdoc-sdk v1.8.0-next.89 |
Contributor
|
🎉 This PR is included in superdoc v1.30.0-next.87 The release is available on GitHub release |
msviderok
pushed a commit
to msviderok/superdoc
that referenced
this pull request
May 16, 2026
…t unknown (SD-3139) (superdoc-dev#3281) Follow-up to SD-3131 (superdoc-dev#3275). After that PR, imported typeless w:sdtPr correctly resolves to controlType: 'richText' per ECMA-376 §17.5.2.26, but newly created controls via create.contentControl (no controlType) and contentControls.wrap still defaulted to 'unknown'. Customers filtering contentControls.list() by type saw different results before vs after save/reopen — the same typeless OOXML round-tripped from 'unknown' to 'richText'. - createWrapper: collapse three `?? 'unknown'` into a single `?? 'richText'` local. - wrapWrapper: explicitly seed controlType, type, and a default sdtPr with <w:richText/> on the wrapper attrs (previously controlType was unset entirely, leaving resolveControlType to fall back to 'unknown'). Newly created controls now emit explicit <w:richText/> in sdtPr for unambiguous engine state and exported markup. Imported typeless Word-authored SDTs preserve their original raw sdtPr (import path unchanged). Per the SD-3131 design, 'unknown' keeps its meaning of "unsupported or unrecognized type" — it's no longer the default for new controls. Tests: 3 new (default-create → richText, explicit-richText-create seeds <w:richText/>, wrap → richText + seeds <w:richText/>). 42 wrappers + 1189 conformance + 1398 document-api pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to SD-3131 (#3275). After that PR, imported typeless
w:sdtPrcorrectly resolves tocontrolType: 'richText'per ECMA-376 §17.5.2.26, but newly created controls viacreate.contentControl(withcontrolTypeomitted) andcontentControls.wrapstill defaulted to'unknown'. Customers filteringcontentControls.list()by type saw different results before vs after save/reopen — the same typeless OOXML round-tripped from'unknown'to'richText'.create.contentControl({ kind })'unknown''richText'contentControls.wrap'unknown'(resolveControlType fallback)'richText'createWrapper: collapse three?? 'unknown'into a single?? 'richText'local.wrapWrapper: explicitly seedcontrolType,type, and a defaultsdtPrwith<w:richText/>on the wrapper attrs (previouslycontrolTypewas unset entirely, leavingresolveControlTypeto fall back to'unknown').Newly created controls now emit explicit
<w:richText/>insdtPrfor unambiguous engine state and exported markup. Imported typeless Word-authored SDTs preserve their original rawsdtPr(import path unchanged).Per the SD-3131 design,
'unknown'keeps its meaning of "unsupported or unrecognized type" — it's no longer the default for new controls.Tests: 3 new — default-create → richText, explicit-richText-create seeds
<w:richText/>, wrap → richText + seeds<w:richText/>. 42 wrappers + 1189 conformance + 1398 document-api pass. Zero new TypeScript errors.Non-blocking follow-up:
create.contentControlandsetTypestill accept explicitcontrolType: 'unknown'because'unknown'is in the shared read/write enum. That can produce stable-but-deliberately-unknown controls, which is a separate API-shape question — worth tightening mutation validation if'unknown'should be read-only. Not blocking this PR.Related: SD-3131.