@eigenpal/docx-editor-vue@1.8.3
- Updated dependencies [88a7650]
- Updated dependencies [5ce3faa]
- Updated dependencies [5eb0a43]
- Updated dependencies [673e917]
- Updated dependencies [74e36ef]
- Updated dependencies [447d5b0]
- @eigenpal/docx-editor-core@1.8.3
- @eigenpal/docx-editor-agents@1.8.3
- @eigenpal/docx-editor-i18n@1.8.3
@eigenpal/docx-editor-react@1.8.3
- 5ce3faa: Escape embedded font-family names before interpolating into the injected
@font-facestylesheet, and build the print window via DOM APIs instead ofdocument.writestring concatenation. Prevents CSS injection and print-time XSS from crafted DOCX font names. - Updated dependencies [88a7650]
- Updated dependencies [5ce3faa]
- Updated dependencies [5eb0a43]
- Updated dependencies [673e917]
- Updated dependencies [74e36ef]
- Updated dependencies [447d5b0]
- @eigenpal/docx-editor-core@1.8.3
- @eigenpal/docx-editor-agents@1.8.3
- @eigenpal/docx-editor-i18n@1.8.3
@eigenpal/docx-editor-core@1.8.3
-
88a7650: Support RTL tables with
w:bidiVisualalignment. -
5ce3faa: Escape embedded font-family names before interpolating into the injected
@font-facestylesheet, and build the print window via DOM APIs instead ofdocument.writestring concatenation. Prevents CSS injection and print-time XSS from crafted DOCX font names. -
5eb0a43: Allowlist URL schemes on hyperlink and image-hyperlink targets parsed from DOCX relationships and pasted HTML;
javascript:,data:, and other non-web schemes are now dropped. -
673e917: Render RTL tables (
w:bidiVisual) with their columns in visual right-to-left order, matching Word. The bidi flag was already parsed and round-tripped, but the on-page painter still drew columns left-to-right, so in a right-to-left table a label cell appeared on the wrong side of the field it labels.Fixes #734
-
74e36ef: Build shape SVG via DOM APIs instead of innerHTML, preventing XSS from crafted DOCX shape attributes.
-
447d5b0: Fix Japanese/CJK IME input garbling text in suggesting mode. Composed text was re-inserted via
handleTextInput, duplicating surrounding content and marking it as a tracked change. Suggesting mode now stays out of the way during composition and marks the committed text once it settles.
v16.3.0-canary.59
- Upgrade to swc 70: #94814
- [turbopack] Sort modules in chunks to reduce duplicates: #94961
- router instrumentation: refactor client hook dispatch (1/7): #94755
- [otel] Add more verbose-mode OTEL spans for App Router: #94894
- Enforce route segment configs on metadata routes under Cache Components: #94962
- typegen: default to Turbopack: #94952
- router instrumentation: add transition start context (2/7): #94766
- fix: after(callback) called after response end: #94974
- fix: request APIs in promises passed to after() in actions/handlers: #94964
Huge thanks to @mischnic, @sampoder, @feedthejim, @unstubbable, @wbinnssmith, and @lubieowoce for helping!
💎 Version 5.15.2
An animated chart (e.g. an area chart) schedules a requestAnimationFrame during render() to run its mask-reveal / draw animation. If the chart was destroyed before that frame fired, the stale callback ran against already-cleared DOM and threw:
TypeError: Cannot read properties of null (reading 'node') // in runMaskReveal
The classic trigger is React StrictMode, which mounts → unmounts → remounts a component in development: the first mount queues the animation frame, the unmount calls destroy() (which nulls w.dom.elDefs), and the queued frame then fires against the torn-down chart. Any sufficiently rapid unmount hit the same race.
The fix adds an internal isDestroyed flag, set by destroy() (but not by updates), that the deferred draw-animation callbacks - mask reveal, stroke draw, and bulk reveal - check and bail on before touching the DOM. The flag is cleared on the next render, so re-mounting re-arms animations normally.
This complements the detached-chart destroy() fix in 5.15.1; together they resolve the teardown crashes tracked in react-apexcharts#602.
astro@7.0.0-beta.6
-
#17116
f95e58eThanks @ascorbic! - Stabilizes route caching, removing theexperimental.cacheandexperimental.routeRulesflags and replacing them with the top-levelcacheandrouteRulesconfiguration options.Route caching, introduced experimentally in v6.0.0, is now stable. It gives you a platform-agnostic way to cache responses from on-demand rendered pages and endpoints, based on standard HTTP caching semantics.
Update your config to move
cacheandrouteRulesout of theexperimentalblock:// astro.config.mjs import { defineConfig, memoryCache } from 'astro/config'; export default defineConfig({ - experimental: { - cache: { - provider: memoryCache(), - }, - routeRules: { - '/blog/[...path]': { maxAge: 300, swr: 60 }, - }, - }, + cache: { + provider: memoryCache(), + }, + routeRules: { + '/blog/[...path]': { maxAge: 300, swr: 60 }, + }, });Set caching directives in your routes with
Astro.cache(in.astropages) orcontext.cache(in API routes and middleware), and Astro translates them into the appropriate headers or runtime behavior depending on your configured cache provider. You can also define cache rules for routes declaratively in your config usingrouteRules, without modifying route code.See the route caching guide for more information.