Related Feature
Feature request: N/A
Description
After adding appdescr_ui5_setFlexExtensionPointEnabled.change to the watchManifestChanges() file watcher in @sap-ux/reload-middleware, the merged manifest served during sandbox HTML generation includes flexExtensionPointEnabled: true in sap.ui5. UI5 versions below 1.120 cannot handle this property at bootstrap time, causing the preview iframe to render as a blank white page after a reload in the Adaptation Editor.
This regression was introduced when reload-middleware@0.3.19 added appdescr_ui5_setFlexExtensionPointEnabled.change to the list of changes that trigger __SAP_UX_MANIFEST_SYNC_REQUIRED__. Previously, saving this change did not trigger a manifest re-sync, so the served manifest did not include the property and older UI5 versions loaded fine.
Affected packages:
@sap-ux/preview-middleware
@sap-ux/reload-middleware
Steps to Reproduce
- Open an ADP (Adaptation Project) with extension points in the Adaptation Editor using UI5 version 1.108.51 (or 1.96.46)
- Right-click an extension point → Add Fragment at Extension Point → enter a fragment name → Create → Save
- Both
addXMLAtExtensionPoint.change and appdescr_ui5_setFlexExtensionPointEnabled.change are saved
- Edit the created fragment XML to add a
<Button text="Click me">
- "Changes detected!" appears → click Reload
- The preview iframe stays blank — the app fails to bootstrap
Alternatively for Step 3 of the integration test: pre-load existing change files that include setFlexExtensionPointEnabled.change and open the editor — the app never renders.
Expected results
After reload, the app renders correctly with the new fragment content visible. The flexExtensionPointEnabled property should be stripped from the applicationDependencies manifest for UI5 versions below 1.120.
Actual results
The preview iframe is blank (white). The outline shows "No control found" and the changes panel shows "No historic changes" after reload. The app fails to bootstrap silently.
Version/Components/Environment
Root Cause Analysis
Problem
reload-middleware/src/base/livereload.ts watchManifestChanges() was updated to include appdescr_ui5_setFlexExtensionPointEnabled.change in the list of file changes that set __SAP_UX_MANIFEST_SYNC_REQUIRED__ = true. This causes AdpPreview.sync() to re-merge the manifest from the backend, which now includes flexExtensionPointEnabled: true in sap.ui5. When FlpSandbox serves the sandbox HTML, this property is included in sap-ushell-config.applications[app].applicationDependencies.manifest. UI5 versions < 1.120 cannot process this manifest property during bootstrap and fail silently (blank page).
Fix
Add a removeFlexExtensionPointEnabled() method to FlpSandbox in preview-middleware/src/base/flp.ts that strips manifest['sap.ui5'].flexExtensionPointEnabled from applicationDependencies when UI5 version is < 1.120. This follows the same pattern as removeAsyncHintsRequests() for UI5 <= 1.71. The method is called from both generateSandboxForEditor() and flpGetHandler().
Why was it missed
The watchManifestChanges() change was correct in intent (the manifest should re-sync when setFlexExtensionPointEnabled is saved). However, the downstream effect on older UI5 versions was not tested — the integration tests only caught this in the nightly CI pipeline, not during development.
Related Feature
Feature request: N/A
Description
After adding
appdescr_ui5_setFlexExtensionPointEnabled.changeto thewatchManifestChanges()file watcher in@sap-ux/reload-middleware, the merged manifest served during sandbox HTML generation includesflexExtensionPointEnabled: trueinsap.ui5. UI5 versions below 1.120 cannot handle this property at bootstrap time, causing the preview iframe to render as a blank white page after a reload in the Adaptation Editor.This regression was introduced when
reload-middleware@0.3.19addedappdescr_ui5_setFlexExtensionPointEnabled.changeto the list of changes that trigger__SAP_UX_MANIFEST_SYNC_REQUIRED__. Previously, saving this change did not trigger a manifest re-sync, so the served manifest did not include the property and older UI5 versions loaded fine.Affected packages:
@sap-ux/preview-middleware@sap-ux/reload-middlewareSteps to Reproduce
addXMLAtExtensionPoint.changeandappdescr_ui5_setFlexExtensionPointEnabled.changeare saved<Button text="Click me">Alternatively for Step 3 of the integration test: pre-load existing change files that include
setFlexExtensionPointEnabled.changeand open the editor — the app never renders.Expected results
After reload, the app renders correctly with the new fragment content visible. The
flexExtensionPointEnabledproperty should be stripped from theapplicationDependenciesmanifest for UI5 versions below 1.120.Actual results
The preview iframe is blank (white). The outline shows "No control found" and the changes panel shows "No historic changes" after reload. The app fails to bootstrap silently.
Version/Components/Environment
Root Cause Analysis
Problem
reload-middleware/src/base/livereload.tswatchManifestChanges()was updated to includeappdescr_ui5_setFlexExtensionPointEnabled.changein the list of file changes that set__SAP_UX_MANIFEST_SYNC_REQUIRED__ = true. This causesAdpPreview.sync()to re-merge the manifest from the backend, which now includesflexExtensionPointEnabled: trueinsap.ui5. WhenFlpSandboxserves the sandbox HTML, this property is included insap-ushell-config.applications[app].applicationDependencies.manifest. UI5 versions < 1.120 cannot process this manifest property during bootstrap and fail silently (blank page).Fix
Add a
removeFlexExtensionPointEnabled()method toFlpSandboxinpreview-middleware/src/base/flp.tsthat stripsmanifest['sap.ui5'].flexExtensionPointEnabledfromapplicationDependencieswhen UI5 version is < 1.120. This follows the same pattern asremoveAsyncHintsRequests()for UI5 <= 1.71. The method is called from bothgenerateSandboxForEditor()andflpGetHandler().Why was it missed
The
watchManifestChanges()change was correct in intent (the manifest should re-sync whensetFlexExtensionPointEnabledis saved). However, the downstream effect on older UI5 versions was not tested — the integration tests only caught this in the nightly CI pipeline, not during development.