2026-04-27 18:55:12 +02:00
|
|
|
import {
|
|
|
|
|
checkForScreenshot,
|
|
|
|
|
screenShotPaths,
|
|
|
|
|
test,
|
|
|
|
|
visitStudy,
|
|
|
|
|
waitForViewportRenderCycle,
|
|
|
|
|
waitForViewportsRendered,
|
|
|
|
|
} from './utils';
|
2025-02-26 17:23:40 +01:00
|
|
|
|
|
|
|
|
test.beforeEach(async ({ page }) => {
|
|
|
|
|
const studyInstanceUID = '1.3.12.2.1107.5.2.32.35162.30000015050317233592200000046';
|
|
|
|
|
const mode = 'viewer';
|
|
|
|
|
await visitStudy(page, studyInstanceUID, mode, 2000);
|
|
|
|
|
});
|
|
|
|
|
|
2025-12-12 17:46:45 +01:00
|
|
|
test('should properly display MPR for MR', async ({
|
|
|
|
|
page,
|
|
|
|
|
DOMOverlayPageObject,
|
|
|
|
|
leftPanelPageObject,
|
|
|
|
|
mainToolbarPageObject,
|
|
|
|
|
rightPanelPageObject,
|
2026-04-27 18:55:12 +02:00
|
|
|
viewportPageObject,
|
2025-12-12 17:46:45 +01:00
|
|
|
}) => {
|
|
|
|
|
await rightPanelPageObject.toggle();
|
2025-04-04 18:11:29 +02:00
|
|
|
|
2025-11-20 15:29:14 +01:00
|
|
|
await mainToolbarPageObject.layoutSelection.MPR.click();
|
2025-04-04 18:11:29 +02:00
|
|
|
|
2026-04-27 18:55:12 +02:00
|
|
|
await waitForViewportsRendered(page);
|
|
|
|
|
|
|
|
|
|
await checkForScreenshot(
|
|
|
|
|
page,
|
|
|
|
|
viewportPageObject.grid,
|
|
|
|
|
screenShotPaths.segHydrationFromMPR.mprBeforeSEG
|
|
|
|
|
);
|
2025-04-04 18:11:29 +02:00
|
|
|
|
2025-12-12 17:46:45 +01:00
|
|
|
await leftPanelPageObject.loadSeriesByDescription('SEG');
|
2025-02-26 17:23:40 +01:00
|
|
|
|
fix(docs): remove stray tool-call tags breaking the MDX build (#6081)
This is a fix to pnpm deployment which needs testing as the final part of origin/master release
No functional changes
* fix(docs): remove stray tool-call tags breaking the MDX build
platform/docs/docs/migration-guide/3p12-to-3p13/build-tooling.md ended with
two orphan closing tags (leftover tool-call serialization artifacts):
</content>
</invoke>
Docusaurus compiles Markdown as MDX (JSX-aware), so the orphan closing tag
failed the docs build:
MDX compilation failed ... Unexpected closing slash in tag, expected an
open tag first (build-tooling.md line 402)
This was the remaining blocker for build-and-deploy-docs once the
--no-frozen-lockfile change let the install step succeed. A scan of the docs
tree found no other such artifacts. Verified locally: docusaurus build now
generates static files with no MDX errors.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Update lockfile and avoid freshness check on every command
* fix(release): keep workspace:* in the repo, concretize only at publish
The release flow rewrote internal @ohif/* dependency specifiers to the concrete
version and committed them, so pnpm-lock.yaml (which records workspace links)
drifted from the manifests on every version bump. The resulting
ERR_PNPM_OUTDATED_LOCKFILE broke every frozen install: Netlify (viewer-dev),
the docs deploy, pnpm's pre-run deps check, and post-merge installs.
Keep workspace:* everywhere in the committed repo and move the concrete-version
substitution to publish time only:
- publish-version.mjs: bump each package's own `version` field only; stop
rewriting @ohif/* dependency/peerDependency specifiers.
- publish-package.mjs: publish with `pnpm publish --no-git-checks` instead of
`npm publish`. pnpm rewrites workspace:* to the exact version in the published
tarball; npm would publish the literal "workspace:*", which npm/yarn consumers
cannot resolve.
- One-time: revert the 25 workspace manifests' @ohif/* specifiers to workspace:*
(version fields untouched) and regenerate pnpm-lock.yaml to match.
Because internal deps are workspace:* (links, not versions in the lockfile),
version bumps no longer change pnpm-lock.yaml, so it stays in sync and frozen
installs keep working.
Verified: `pnpm install --frozen-lockfile` passes, and `pnpm pack` of @ohif/core
emits a tarball whose @ohif/ui dependency is the exact version (3.13.0-beta.92),
not workspace:*.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(ci): correct build-docs install comment for workspace:* release flow
publish-version.mjs no longer rewrites @ohif/* deps to concrete versions, so
the old comment was stale. Internal deps stay workspace:* and the lockfile
stays consistent; pnpm publish concretizes only the published tarball.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci(docs): use --frozen-lockfile now that the lockfile no longer drifts
With internal deps as workspace:* the lockfile stays in sync across version
bumps, so the docs deploy can install frozen -- failing fast on genuine
lockfile drift instead of silently reconciling. The --no-frozen-lockfile
workaround is no longer needed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: use --frozen-lockfile in CI install steps now that the lockfile is stable
Internal @ohif/* deps are workspace:* so pnpm-lock.yaml no longer drifts; the
UNIT_TESTS/BUILD/NPM_PUBLISH installs can run frozen and fail fast on genuine
drift. Kept --no-frozen-lockfile only where it is still required: the Dockerfile
(platform/docs is excluded from the build context) and the playwright CS3D-version
step (mutates @cornerstonejs versions before installing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test: stability of seg load mpr test
* Better drag fix for crosshairs
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 17:59:04 +02:00
|
|
|
// SEG load triggers a progressive labelmap volume upload. waitForViewportsRendered
|
|
|
|
|
// (waitVolumeLoad defaults to true) polls the viewport volume actors until the
|
|
|
|
|
// labelmap reports loadStatus.loaded, then settles, so the screenshot captures the
|
|
|
|
|
// finished upload rather than a mid-stream frame.
|
2026-04-27 18:55:12 +02:00
|
|
|
await waitForViewportsRendered(page);
|
|
|
|
|
|
|
|
|
|
await checkForScreenshot(
|
|
|
|
|
page,
|
|
|
|
|
viewportPageObject.grid,
|
|
|
|
|
screenShotPaths.segHydrationFromMPR.mprAfterSEG
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// start watching for viewports to render
|
|
|
|
|
const viewportRenderCycle = waitForViewportRenderCycle(page);
|
2025-04-04 18:11:29 +02:00
|
|
|
|
2025-12-12 17:46:45 +01:00
|
|
|
await DOMOverlayPageObject.viewport.segmentationHydration.yes.click();
|
2025-04-04 18:11:29 +02:00
|
|
|
|
2026-04-27 18:55:12 +02:00
|
|
|
await viewportRenderCycle;
|
fix(docs): remove stray tool-call tags breaking the MDX build (#6081)
This is a fix to pnpm deployment which needs testing as the final part of origin/master release
No functional changes
* fix(docs): remove stray tool-call tags breaking the MDX build
platform/docs/docs/migration-guide/3p12-to-3p13/build-tooling.md ended with
two orphan closing tags (leftover tool-call serialization artifacts):
</content>
</invoke>
Docusaurus compiles Markdown as MDX (JSX-aware), so the orphan closing tag
failed the docs build:
MDX compilation failed ... Unexpected closing slash in tag, expected an
open tag first (build-tooling.md line 402)
This was the remaining blocker for build-and-deploy-docs once the
--no-frozen-lockfile change let the install step succeed. A scan of the docs
tree found no other such artifacts. Verified locally: docusaurus build now
generates static files with no MDX errors.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Update lockfile and avoid freshness check on every command
* fix(release): keep workspace:* in the repo, concretize only at publish
The release flow rewrote internal @ohif/* dependency specifiers to the concrete
version and committed them, so pnpm-lock.yaml (which records workspace links)
drifted from the manifests on every version bump. The resulting
ERR_PNPM_OUTDATED_LOCKFILE broke every frozen install: Netlify (viewer-dev),
the docs deploy, pnpm's pre-run deps check, and post-merge installs.
Keep workspace:* everywhere in the committed repo and move the concrete-version
substitution to publish time only:
- publish-version.mjs: bump each package's own `version` field only; stop
rewriting @ohif/* dependency/peerDependency specifiers.
- publish-package.mjs: publish with `pnpm publish --no-git-checks` instead of
`npm publish`. pnpm rewrites workspace:* to the exact version in the published
tarball; npm would publish the literal "workspace:*", which npm/yarn consumers
cannot resolve.
- One-time: revert the 25 workspace manifests' @ohif/* specifiers to workspace:*
(version fields untouched) and regenerate pnpm-lock.yaml to match.
Because internal deps are workspace:* (links, not versions in the lockfile),
version bumps no longer change pnpm-lock.yaml, so it stays in sync and frozen
installs keep working.
Verified: `pnpm install --frozen-lockfile` passes, and `pnpm pack` of @ohif/core
emits a tarball whose @ohif/ui dependency is the exact version (3.13.0-beta.92),
not workspace:*.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(ci): correct build-docs install comment for workspace:* release flow
publish-version.mjs no longer rewrites @ohif/* deps to concrete versions, so
the old comment was stale. Internal deps stay workspace:* and the lockfile
stays consistent; pnpm publish concretizes only the published tarball.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci(docs): use --frozen-lockfile now that the lockfile no longer drifts
With internal deps as workspace:* the lockfile stays in sync across version
bumps, so the docs deploy can install frozen -- failing fast on genuine
lockfile drift instead of silently reconciling. The --no-frozen-lockfile
workaround is no longer needed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: use --frozen-lockfile in CI install steps now that the lockfile is stable
Internal @ohif/* deps are workspace:* so pnpm-lock.yaml no longer drifts; the
UNIT_TESTS/BUILD/NPM_PUBLISH installs can run frozen and fail fast on genuine
drift. Kept --no-frozen-lockfile only where it is still required: the Dockerfile
(platform/docs is excluded from the build context) and the playwright CS3D-version
step (mutates @cornerstonejs versions before installing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test: stability of seg load mpr test
* Better drag fix for crosshairs
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 17:59:04 +02:00
|
|
|
// Hydration propagates the labelmap volume to the sagittal/coronal MPR viewports
|
|
|
|
|
// asynchronously, adding new volume actors after the first render cycle resolves.
|
|
|
|
|
// waitForViewportsRendered re-polls every viewport's volume actors until those
|
|
|
|
|
// propagated labelmaps report loadStatus.loaded, then settles.
|
|
|
|
|
await waitForViewportsRendered(page);
|
2026-04-27 18:55:12 +02:00
|
|
|
|
|
|
|
|
await checkForScreenshot(
|
|
|
|
|
page,
|
|
|
|
|
viewportPageObject.grid,
|
|
|
|
|
screenShotPaths.segHydrationFromMPR.mprAfterSegHydrated
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const viewportRenderAfterLayoutChange = waitForViewportRenderCycle(page);
|
2025-02-26 17:23:40 +01:00
|
|
|
|
2025-11-20 15:29:14 +01:00
|
|
|
await mainToolbarPageObject.layoutSelection.axialPrimary.click();
|
2025-02-26 17:23:40 +01:00
|
|
|
|
2026-04-27 18:55:12 +02:00
|
|
|
await viewportRenderAfterLayoutChange;
|
fix(docs): remove stray tool-call tags breaking the MDX build (#6081)
This is a fix to pnpm deployment which needs testing as the final part of origin/master release
No functional changes
* fix(docs): remove stray tool-call tags breaking the MDX build
platform/docs/docs/migration-guide/3p12-to-3p13/build-tooling.md ended with
two orphan closing tags (leftover tool-call serialization artifacts):
</content>
</invoke>
Docusaurus compiles Markdown as MDX (JSX-aware), so the orphan closing tag
failed the docs build:
MDX compilation failed ... Unexpected closing slash in tag, expected an
open tag first (build-tooling.md line 402)
This was the remaining blocker for build-and-deploy-docs once the
--no-frozen-lockfile change let the install step succeed. A scan of the docs
tree found no other such artifacts. Verified locally: docusaurus build now
generates static files with no MDX errors.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Update lockfile and avoid freshness check on every command
* fix(release): keep workspace:* in the repo, concretize only at publish
The release flow rewrote internal @ohif/* dependency specifiers to the concrete
version and committed them, so pnpm-lock.yaml (which records workspace links)
drifted from the manifests on every version bump. The resulting
ERR_PNPM_OUTDATED_LOCKFILE broke every frozen install: Netlify (viewer-dev),
the docs deploy, pnpm's pre-run deps check, and post-merge installs.
Keep workspace:* everywhere in the committed repo and move the concrete-version
substitution to publish time only:
- publish-version.mjs: bump each package's own `version` field only; stop
rewriting @ohif/* dependency/peerDependency specifiers.
- publish-package.mjs: publish with `pnpm publish --no-git-checks` instead of
`npm publish`. pnpm rewrites workspace:* to the exact version in the published
tarball; npm would publish the literal "workspace:*", which npm/yarn consumers
cannot resolve.
- One-time: revert the 25 workspace manifests' @ohif/* specifiers to workspace:*
(version fields untouched) and regenerate pnpm-lock.yaml to match.
Because internal deps are workspace:* (links, not versions in the lockfile),
version bumps no longer change pnpm-lock.yaml, so it stays in sync and frozen
installs keep working.
Verified: `pnpm install --frozen-lockfile` passes, and `pnpm pack` of @ohif/core
emits a tarball whose @ohif/ui dependency is the exact version (3.13.0-beta.92),
not workspace:*.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(ci): correct build-docs install comment for workspace:* release flow
publish-version.mjs no longer rewrites @ohif/* deps to concrete versions, so
the old comment was stale. Internal deps stay workspace:* and the lockfile
stays consistent; pnpm publish concretizes only the published tarball.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci(docs): use --frozen-lockfile now that the lockfile no longer drifts
With internal deps as workspace:* the lockfile stays in sync across version
bumps, so the docs deploy can install frozen -- failing fast on genuine
lockfile drift instead of silently reconciling. The --no-frozen-lockfile
workaround is no longer needed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: use --frozen-lockfile in CI install steps now that the lockfile is stable
Internal @ohif/* deps are workspace:* so pnpm-lock.yaml no longer drifts; the
UNIT_TESTS/BUILD/NPM_PUBLISH installs can run frozen and fail fast on genuine
drift. Kept --no-frozen-lockfile only where it is still required: the Dockerfile
(platform/docs is excluded from the build context) and the playwright CS3D-version
step (mutates @cornerstonejs versions before installing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test: stability of seg load mpr test
* Better drag fix for crosshairs
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 17:59:04 +02:00
|
|
|
// The layout change rebuilds the viewports; wait for their volume actors (image
|
|
|
|
|
// + labelmap) to report loaded before settling and capturing.
|
|
|
|
|
await waitForViewportsRendered(page);
|
2026-04-27 18:55:12 +02:00
|
|
|
|
2025-02-26 17:23:40 +01:00
|
|
|
await checkForScreenshot(
|
|
|
|
|
page,
|
2026-04-27 18:55:12 +02:00
|
|
|
viewportPageObject.grid,
|
2025-04-04 18:11:29 +02:00
|
|
|
screenShotPaths.segHydrationFromMPR.mprAfterSegHydratedAfterLayoutChange
|
2025-02-26 17:23:40 +01:00
|
|
|
);
|
|
|
|
|
});
|