[BUG]: Attempting to view a mapping in the manual mapping tab doesn't work

[iduarteandeco]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If you navigate to the Manual mapping tab, then click on a mapped entity and attempt to then click on the rightmost "mapping" tab in the popup that appears at the bottom it just hangs forever and doesn't display the generated mapping.

Expected Behavior

You should be able to view the mapping.

Steps To Reproduce

1. Auto generate a mapping
2. Navigate to the manual mapping to review the generated mapping
3. Click on one of the entities
4. Click on the rightmost tab in the bottom popup
5. Observe that it just hangs rather than displaying the mapping

Cloud

AWS

Browser

Firefox

OntoBricks Version

0.7.1

Relevant log output

Additional Context

No response

[benoitcayladbx]

Reproduced and root-caused — thanks for the precise repro steps, they pointed straight at it.

Root cause

The Manual Mapping bottom panel is not its own UI: it reuses the Designer's entity/relationship panel by rendering loadEntityPanelContent() / loadRelationshipPanelContent() into #manualPanelBody.

For an already-mapped entity that markup starts with the spinner visible and the results grid hidden, then kicks off a preview query against /mapping/test-query. The success handler is what hides the spinner and reveals the grid — but it first checks that a panel is actually open:

// Discard stale response if the user switched to a different entity
if (currentPanelType !== 'entity' || capturedGeneration !== EntityPanelState._generation) return;

currentPanelType was only ever set by openEntityMappingFromDesign() / openRelationshipMappingFromDesign(). Manual Mapping never touched it, so it stayed null, the query returned 200 with the rows, the handler bailed out on the guard, and #epMappingLoading was never hidden. Hence the permanent spinner. Same trap on the relationship path (currentPanelType !== 'relationship').

That is why the Mapping tab works in the visual Designer but not in Manual Mapping. It is not browser- or cloud-specific — Firefox/AWS just happened to be where you hit it.

There is a second, latent defect on the same path: the panel markup uses page-global ep* / rp* element ids, and the Designer and Manual sections both live in the DOM at once. If you opened a Designer panel first, its leftover copy shadowed the Manual one on every getElementById lookup, so results could render into the hidden Designer panel instead.

Fix

Panel ownership is now tracked explicitly:

• claimMappingPanel() records which host (#panelBody or #manualPanelBody) received the markup, sets the panel type/URI, and closes the other host so only one copy of the ep* / rp* ids exists.
• releaseMappingPanel() drops ownership and invalidates in-flight preview queries; both hosts call it on teardown.
• closeActiveMappingPanel() dispatches to whichever host owns the panel — Manual Mapping's Auto-Map shares the Designer's poll loop and used to leave its panel open with stale content.

Both loaders claim the panel before initialising it, so the preview query passes the stale-response guard regardless of which section rendered it.

Committed on develop and backported to 0.7.2, with a regression test (tests/units/front/test_manual_mapping_panel_host.py) that fails on the pre-fix code.