Buttons greyed out in Linux install

[Greggles2026]

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

[cosminef]

Hello,

The action is disabled because the DITA Map is currently in a read-only state. Please check the permissions for the DITA Map and make sure that the user has the necessary permissions to edit it.

Another condition is that the configured URL chooser must support the EXTERNAL_REF type.
https://www.oxygenxml.com/maven/com/oxy ... pe__anchor

Best,
Cosmin

[Greggles2026]

The map is not read_only. I can edit it and save changes.
The buttons worked perfectly in a local Windows install. When deployed to a Linux install based on the same code and customizations the buttons are greyed out.
Ideas?

Thanks in advance,
Greg

[mihaela]

Hello,

The action checks the following conditions to determine whether it is enabled:
1. The editor is not read-only.
2. The caret or selection is placed in editable content.
3. The file chooser supports the EXTERNAL_REF type.

You already mentioned that the editor is not read-only, and I assume that the caret is placed in editable content. You can therefore check the last condition by running the following command in the browser's developer console:

Code: Select all

workspace.getUrlChooser().supports(sync.api.UrlChooser.Type.EXTERNAL_REF)

Please check whether the returned value is true.


Best Regards,
Mihaela