Open dobri1408 opened 1 week ago
Name | Link |
---|---|
Latest commit | 4518dd92fb5710f9b5e08bf7d93cf7298738b5d3 |
Latest deploy log | https://app.netlify.com/sites/plone-components/deploys/662a30944f90e20008aa3b83 |
Name | Link |
---|---|
Latest commit | 4518dd92fb5710f9b5e08bf7d93cf7298738b5d3 |
Latest deploy log | https://app.netlify.com/sites/volto/deploys/662a3094fb572f0008887232 |
@dobri1408 are you sure that this does not break the original intention of the code (https://github.com/plone/volto/issues/4230). Apparently, seems it does not, but still.
@sneridagh, @tiberiuichim @ichim-david , I believe there might be a misunderstanding. Consider this perspective: the field in question is displayed in the sidebar, as indicated by the className being sidebar-metadata. Therefore, if we are not operating within the sidebar context, it seems unnecessary to focus on these fields. Also it can be a potential bug, as I have shown you. My condition ensures we check whether we are in the sidebar or not.
Seems strange passing react props derived from the state of the DOM elements in the browser
@sneridagh I'm putting the pull request in draft until we have a better look at the problem and consider if we need to handle it from Volto core. This is a problem of our doing within our add-on https://github.com/eea/volto-metadata-block/ that allows you to mirror the content type fields from the sidebar to the content area. Because it renders with the same id and widget when there is a field with a react-select and given the field id it focuses on the sidebar which is bad if you interact with the widget in the content area.
Given Tiberiu's comment even if we do propose something for the core we might need todo it differently so for now we treat it as review given and we still have some work todo.
When editing metadata externally, as in the case of our EEA metadata block, the current functionality causes the sidebar to automatically gain focus. However, this behavior is unnecessary in this context and results in the sidebar capturing focus inappropriately. To address this, I propose a solution where the sidebar will only receive focus if the user is actively working within it. This can be achieved by checking the activeElement to determine if the sidebar should be focused.
screen-capture.webm