Buttons greyed out in Linux install
Posted: Fri Aug 21, 2026 12:09 am
Issue summary — Oxygen XML Web Author, custom DITA regulation frameworks
Environment: Oxygen XML Web Author 28.0.0 (28.0.0.0 client build), Linux UAT server (Tomcat, bundled JRE, JVM 17.0.17). Four custom regulation frameworks, each built as a Framework Extension Script (.exf, base="DITA Map") extending the built-in DITA Map framework. Content served via a custom regulations:// URL protocol (URLStreamHandlerPluginExtension).
Affected actions: "Create a new DITA resource and create a reference to it" (insert.new.dita.resource) and "Insert a DITA topic reference to an existing resource" (insert.topicref).
Symptom: Both actions render correctly on the DITA Map toolbar/menu/contextual menu on my local Windows-based install but on our Linux UAT deployment they appear greyed out and do not respond to clicks — no console output and no network activity fires on click. The same framework code, deployed to a local Windows install, works correctly for both actions.
What we've ruled out:
Framework/toolbar declarations are byte-identical to the stock DITA Map framework for these two actions.
Our custom regulations:// connector's listFolder()/getOutputStream() implementation (decompiled and reviewed) contains no capability restriction that would block these actions — it's a straightforward file read/write.
JVM startup flags (--add-opens, -Djava.security.manager) are correctly configured for Java 17; no InaccessibleObjectException in server logs.
Server logs show a persistent warning on every document load: Action with ID referenced in the content completion window or menus: insert.new.dita.resource is not declared (and the same for insert.topicref) — but this pattern is also present in earlier working states, so we don't believe it's fully explanatory on its own.
Forcing actionsManager.refreshActionsStatus() on these two action IDs after confirming they're registered (getActionById() returns a real object, not undefined) produces no change in button state.
Current understanding: Since both actions are @WebappCompatible(false) on the Java side, they're normally expected to be entirely absent from the Web Author toolbar unless your bundled client-side script (insert-new-topic-ref-ditamap-action-handler.js) successfully registers a compatible JavaScript replacement (sync.actions.InsertNewTopicRef / the topicref equivalent) in their place. Since the buttons do render on our UAT deployment, we believe that replacement registration is succeeding — but the resulting action's own isEnabled() appears to be evaluating to false, with no client-side error or network call marking why.
Question for support: What condition(s) does sync.actions.InsertNewTopicRef's isEnabled() check internally, and what server- or client-side condition in our environment could cause it to return false silently (no thrown exception, no UserActionRequiredException/CUSTOM_MESSAGE_RECEIVED message) specifically on this Linux deployment while working correctly on an identical Windows install?
More directly, what's the fix for getting this to work? It works on Windows and should work on Linux.
Thanks in advance,
Greg
Environment: Oxygen XML Web Author 28.0.0 (28.0.0.0 client build), Linux UAT server (Tomcat, bundled JRE, JVM 17.0.17). Four custom regulation frameworks, each built as a Framework Extension Script (.exf, base="DITA Map") extending the built-in DITA Map framework. Content served via a custom regulations:// URL protocol (URLStreamHandlerPluginExtension).
Affected actions: "Create a new DITA resource and create a reference to it" (insert.new.dita.resource) and "Insert a DITA topic reference to an existing resource" (insert.topicref).
Symptom: Both actions render correctly on the DITA Map toolbar/menu/contextual menu on my local Windows-based install but on our Linux UAT deployment they appear greyed out and do not respond to clicks — no console output and no network activity fires on click. The same framework code, deployed to a local Windows install, works correctly for both actions.
What we've ruled out:
Framework/toolbar declarations are byte-identical to the stock DITA Map framework for these two actions.
Our custom regulations:// connector's listFolder()/getOutputStream() implementation (decompiled and reviewed) contains no capability restriction that would block these actions — it's a straightforward file read/write.
JVM startup flags (--add-opens, -Djava.security.manager) are correctly configured for Java 17; no InaccessibleObjectException in server logs.
Server logs show a persistent warning on every document load: Action with ID referenced in the content completion window or menus: insert.new.dita.resource is not declared (and the same for insert.topicref) — but this pattern is also present in earlier working states, so we don't believe it's fully explanatory on its own.
Forcing actionsManager.refreshActionsStatus() on these two action IDs after confirming they're registered (getActionById() returns a real object, not undefined) produces no change in button state.
Current understanding: Since both actions are @WebappCompatible(false) on the Java side, they're normally expected to be entirely absent from the Web Author toolbar unless your bundled client-side script (insert-new-topic-ref-ditamap-action-handler.js) successfully registers a compatible JavaScript replacement (sync.actions.InsertNewTopicRef / the topicref equivalent) in their place. Since the buttons do render on our UAT deployment, we believe that replacement registration is succeeding — but the resulting action's own isEnabled() appears to be evaluating to false, with no client-side error or network call marking why.
Question for support: What condition(s) does sync.actions.InsertNewTopicRef's isEnabled() check internally, and what server- or client-side condition in our environment could cause it to return false silently (no thrown exception, no UserActionRequiredException/CUSTOM_MESSAGE_RECEIVED message) specifically on this Linux deployment while working correctly on an identical Windows install?
More directly, what's the fix for getting this to work? It works on Windows and should work on Linux.
Thanks in advance,
Greg