[autocomplete] Where is the debug mode in v5

[ryank425]

• [ x ] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

I am using AutoComplete to list options that match with the query with custom renderOptions function, and have Tooltip on top of those options. I also have some interactions on Tooltip that allow me to drag components to others using React-dnd.

The only way to achieve this is by

1. Add debug prop to --> <Autocomplete debug ...>
2. Add

onMouseDown={(ev) =>{
                ev.stopPropagation();
            }}

to the top of JSX that goes into our tooltip title={...}

Only having two of them set, I can actually drag stuff from the tooltip.

Having onMouseDown to not stopPropagation would result in making all elements to be non draggable.
Having no debug prop on AutoComplete kills any interaction ability as even clicking anything inside tooltip just closes the whole tooltip, not even getting me to the point of dragging.

So, the concern is that I do not see any equivalent option for prop in AutoComplete in v5 version of the documentation. Is there any reason why such function disappeared all of sudden? I really want to try the next version due to some performance issues in v4, but I need this to still work as intended.

Examples 🌈

I don't know if this website is using Material UI components, but the screenshot contains exactly what I want to do in this case. Dragging elements from Tooltip to the outside from AutoComplete options.

Motivation 🔦

[eps1lon]

So, the concern is that I do not see any equivalent option for prop in AutoComplete in v5 version of the documentation. Is there any reason why such function disappeared all of sudden?

See #23377 for all the context

[ryank425]

Having open={true} itself doesn't achieve what the debug mode achieved though.

https://material-ui.com/api/autocomplete/

debug	bool	false	If true, the popup will ignore the blur event if the input is filled. You can inspect the popup markup with your browser tools. Consider this option when you need to customize the component.

I am not trying to inspect the code with popups as I can trigger debugger to freeze the JavaScript Execution to do that. I just want the popup to ignore the blur event if the input is filled.

Having open={true} means I will now have to go through all other additional event listeners like ESC, clicking outside of both Tooltip and Options list to manually change the state, to replicate what the code previously did with not passing open prop, only to have the following functionality: the popup will ignore the blur event if the input is filled.

I agree that the naming of "debug" is bad, but I don't see why this was removed for the single reason of having a better debugging tools nowadays as there are legitimate cases that benefit from having this prop.

[oliviertassinari]

I have just faced the same issue. I need to debug the Autocomplete for #27340 (comment) but I can't. Nor the open prop or

reproduces the same outcome as the debug prop. What I really need to debug is to ignore the blur event.

[ryank425]

@oliviertassinari Can we change the status of the issue, or should this be still remaining as closed?

[oliviertassinari]

@ryank425 Note that this prop was never meant to be enabled in production. We were probably missing a process.env.NODE_ENV = 'production'; to make it a no-op in prod.

[ryank425]

@oliviertassinari Ok, then will Material UI never support any prop that will do following? "the popup will ignore the blur event if the input is filled". Since this is an internal behavior of the library, I don't see how I can leave it open except for manually setting open to true and overriding all other escape behaviors to trigger open to false in the Autocomplete.

[oliviertassinari]

@ryank425 Then it's a completely different discussion, see event.defaultMuiPrevented mui/mui-x#1403. We have started to use it on the Autocomplete, with #23487. In your case, you can easily control the open state, and ignore the onClose event with the blur reason, so I think that we are good.