Cannot read properties of undefined (reading 'hotkey')

[francesc79]

Describe the bug
When opening the page that uses @headless-tree/react, the application immediately throws a runtime error in the browser console:

Uncaught TypeError: Cannot read properties of undefined (reading 'hotkey')
at getDefaultLabel (@headless-tree_react.js?v=cc75ad49:37:44)
at AssistiveTreeDescription (@headless-tree_react.js?v=cc75ad49:56:171)
at react-stack-bottom-frame (react-dom_client.js?v=cc75ad49:17424:20)
at renderWithHooks (react-dom_client.js?v=cc75ad49:4206:24)
at updateFunctionComponent (react-dom_client.js?v=cc75ad49:6619:21)
at beginWork (react-dom_client.js?v=cc75ad49:7654:20)
at runWithFiberInDEV (react-dom_client.js?v=cc75ad49:1485:72)
at performUnitOfWork (react-dom_client.js?v=cc75ad49:10868:98)
at workLoopSync (react-dom_client.js?v=cc75ad49:10728:43)
at renderRootSync (react-dom_client.js?v=cc75ad49:10711:13)

To Reproduce
https://github.com/francesc79/test-mainmenu
npm i && npm run dev

Expected behavior
No error

[lukasbach]

Thanks for reporting! Looks like <AssistiveTreeDescription /> only works if the drag feature is added to the tree. AssistiveTreeDescription only adds screenreader labels required for describing drag operations, the remaining tree is properly described with aria-tags anyway, so as temporary fix you can just change your call of AssistiveTreeDescription to {enableDragAndDrop ? <AssistiveTreeDescription tree={tree} /> : null} to get it working.

I'll fix the underlying issue in AssistiveTreeDescription in the next update.

[francesc79]

Thank you for the clarification. In my case, AssistiveTreeDescription with documentation is not necessary, so no changes are needed.

However, I noticed that keyboard navigation with ArrowUp and ArrowDown is not working in my project. After some investigation, I found that the onTreeMount method inside hotkeysCoreFeature is not receiving any hotkeys from tree.getConfig(), even though the treeFeature appears to set them correctly.

Let me know if you need more details.
Thanks again for your time and support!

Best regards,
Francesco

[lukasbach]

My best guess regarding the hotkey issue is: item.getProps() returns an object that also contains a ref element, make sure that is properly called with the interactive element of the tree item node. If you attach a ref manually after getProps(), you can adjust it so that the ref calls both your custom ref and the one returned by item.getProps(). Note that you can alternatively also call item.registerElement(domNode). You can verify that the element was correctly registered in HT with item.getElement(), it should return the dom node if that has worked.

Another issue I could imagine is that the element registered in HT is not an interactive element: If it is not, I believe the browser will not allow it to receive DOM focus, and thus the keyboard handler will not get invoked. The element should be button or a, or alternatively something that contains a tabindex attribute.

[francesc79]

Hi, lukasbach.

The keyboard navigation issue seems to come from the use of event.code (packages/core/src/features/hotkeys-core/feature.ts row 74). On Linux, for some reason, this field is always set to "NumpadEnter" regardless of the actual key pressed. On the other hand, event.key is correctly populated and works as expected.

Just as a note:

key reflects the actual key pressed (e.g., "Enter", "a", "ArrowDown").

code refers to the physical key on the keyboard (e.g., "KeyA", "NumpadEnter"), regardless of layout or key mapping.

Do you know if code was used here for a specific reason? If not, switching to key might solve the issue across platforms.

Best regards,
Francesco

[lukasbach]

Hm, I see. I actually did use key originally in HT, but that caused also issues since it applies modifiers to the pressed keys instead of tracking modifiers seperately, so e.g. if the user first presses shift and then the a key, the a key is registered as "A", not as "a", and if he then released first shift and then "a", the keyboard-release events where triggered for "a" and not "A", making it really difficult to track which buttons are pressed. And unfortunately just lowercasing it didn't help since there are modifiers for other languages which change more than just upper/lowercasing of keys.

Since you mentioned there is a discrepancy between the clicked key and event.code, what was the actual key that was pressed, was it actually an arrow key that was shown as "NumpadEnter"? Or do you have your keys remapped in such a way?

[francesc79]

You're right that the underlying OS might be influencing the behavior, but I noticed something specific in my case: the KeyboardEvent.code field is consistently set to "NumpadEnter", even when the actual key pressed is something else. Meanwhile, the key field always reflects the correct value — whether it's uppercase or lowercase — based on the user's input.

So for example, when I press a key, event.key gives me the expected character (like "a" or "A", depending on modifiers), but event.code still shows "NumpadEnter", which is clearly unrelated. I don't have any keyboard remapping, so I suspect this discrepancy may come from how the OS or browser handles hardware-level key codes.

Just to clarify: I’m not having issues with the casing of key; it's consistently accurate. The problem lies in the inconsistency or incorrectness of the code field.