There is 1 update, 1 comment.
 
 
XWiki Platform / cid:jira-generated-image-avatar-15e9e1b4-48e4-4789-b4d2-66085c40a2ee XWIKI-18921 Open

Panel Navigation: duplicated IDs

 
View issue   ยท   Add comment
 

1 update

 
cid:jira-generated-image-avatar-51473ccb-9183-49ce-bbd6-b101b09a53c1 Changes by Charpentier Lucas on 20/Jul/26 10:36
 
Assignee: Charpentier Lucas
 
 

1 comment

 
cid:jira-generated-image-avatar-51473ccb-9183-49ce-bbd6-b101b09a53c1 Charpentier Lucas on 20/Jul/26 10:34
 

I'll propose a fix for the anchor duplicated IDs, unfortunately fixing the `li` IDs would break backwards compatibility of xtrees:

jsTree hard-codes the <li>'s rendered id directly from the node's own internal id (it explicitly ignores li_attr.id), and internally re-finds a node's <li> with live DOM id lookups keyed by that same internal id whenever it redraws anything. The only way to make the <li> unique is to change the internal id itself. But that internal id is also jsTree's public identity for the node. It's what get_node/select_node/get_selected event handlers hand back to every caller. Changing it doesn't stay contained to jstree rendering. It breaks every other place in the codebase that reads a jsTree node id. There are at least 6 files in XS with features that would fail if the id changed (locationPicker.js, move.js, entityResourcePicker.js, export.js, ...). I assumed this was too many to just provide a patch for and that this could cause significant backwards compatibility problems in extensions and customizations, which is why I decided it was alright to keep the node IDs

On the other hand the id of the anchor is a pure write. JStree sets it once when rendering the tree, and never reads it back. The node API relies on the node ids instead so it would be off to rely on it in custom scripts. In addition, the `a_attr.id` is an officially supported node field so it should be safe to use.