react-contexify icon indicating copy to clipboard operation
react-contexify copied to clipboard

Menu on closing bug

Open kyro95 opened this issue 3 years ago • 7 comments

Do you want to request a feature or report a bug? Bug

What is the current behavior? Menu pops up for a seconds when closing. https://streamable.com/9ff7um

`const Test = () => { const { show } = useContextMenu({ id: "test" });

return (
    <>
        <div onContextMenu={(e) => {
            show(e, {
                id: "test"
            });
        }}>
            <Menu id={"test"}>
                <Item onClick={(e) => {console.log(2)}}>
                    We
                </Item>
            </Menu>
            WEWEWEWEW
        </div>
    </>
);

}`

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 18.2.0, Firefox, Chrome, Chromium on Windows 11

Also, I'm using Vite to the latest version.

kyro95 avatar Sep 28 '22 22:09 kyro95

I have same question

ZeroJsus avatar Oct 12 '22 08:10 ZeroJsus

@kyro95 has you solve it?

ZeroJsus avatar Oct 12 '22 09:10 ZeroJsus

I think vite is issuing this bug, i've found a temp workaround, you have to play with react states and timers to make appear/disappear the context menu.

kyro95 avatar Oct 12 '22 20:10 kyro95

I think vite is issuing this bug, i've found a temp workaround, you have to play with react states and timers to make appear/disappear the context menu.

I try to control it with react states, failed too....

ZeroJsus avatar Oct 13 '22 06:10 ZeroJsus

I think vite is issuing this bug, i've found a temp workaround, you have to play with react states and timers to make appear/disappear the context menu.

I try to control it with react states, failed too....

Try this out

Use React Effect Hook

const Component = () => {
    useEffect(() => {
        window.addEventListener("mousedown", handleMouseDown);

        return () => {
            window.removeEventListener("keydown", handleKeydown);
        };
    }, [render, setRender]);

    const handleMouseDown = (event: MouseEvent) => {
        setTimeout(() => {
            setRender(false);
        }, 150);
    }

   return (<></>);
}

export {
   Component
};

kyro95 avatar Oct 13 '22 14:10 kyro95

@kyro95

👍 Thank you. Using this code, it works.

Share my implementation.

const Component = () => {
     useEffect(() => {
       window.onmousedown = handleMouseDown;
     }, [render, setRender]);
 
     const handleMouseDown = (event: MouseEvent) => {
         const classNameStr = event?.target?.getAttribute('class');
         if ( classNameStr.indexOf('react-contexify') !== -1 ) {
            setTimeout(() => {
              setRender(false);
            }, 150);
          } else {
            setTimeout(() => {
              setRender(true);
            }, 150);
         }
     }
 
    return (<></>);
 }
 
export {
   Component
}; 

But we still don`t know why this problem occurs, and hopefully it can be solved at all.

ZeroJsus avatar Oct 14 '22 02:10 ZeroJsus

This problem is caused by React 18 update batching. I have created a patch that seems to fix the problem. May patch affects function handleAnimationEnd (in react-contexify.esm.js):

  function handleAnimationEnd() {
    ReactDOM.flushSync(() => {
      if (state.willLeave && state.visible) {
        setState({
          visible: false,
          willLeave: false
        });
      }
    })
  }

I've added flushSync to ensure that these animation end state changes are not batched. Here is my best understanding of why this fixes the problem. It all hinges on how the menu is hidden.

    hasExitAnimation(animation) ? setState(function (state) {
      return {
        willLeave: state.visible
      };
    }) : setState(function (state) {
      return {
        visible: state.visible ? false : state.visible
      };
    });

Assuming the context menu is animated, the system will set willLeave to true. But React 18 batch update logic prevents willLeave from being set to true at the time handleAnimationEnd fires. This since state.willLeave is false, handleAnimationEnd fails to setState visible to false, causing the context menu to remain visible.

I've attached my patch-package that I used to fix the problem on my system. react-contexify+5.0.0.zip

By the way just for the record, I'm upset that the React developers chose to force the concept of batched updates on us. I have had to fight a number of issues, each of them not obvious, both in my own code plus a variety of third-party packages because of this. This has been very costly.

sotarules avatar Oct 15 '22 01:10 sotarules

This problem is caused by React 18 update batching. I have created a patch that seems to fix the problem. May patch affects function handleAnimationEnd (in react-contexify.esm.js):

  function handleAnimationEnd() {
    ReactDOM.flushSync(() => {
      if (state.willLeave && state.visible) {
        setState({
          visible: false,
          willLeave: false
        });
      }
    })
  }

I've added flushSync to ensure that these animation end state changes are not batched. Here is my best understanding of why this fixes the problem. It all hinges on how the menu is hidden.

    hasExitAnimation(animation) ? setState(function (state) {
      return {
        willLeave: state.visible
      };
    }) : setState(function (state) {
      return {
        visible: state.visible ? false : state.visible
      };
    });

Assuming the context menu is animated, the system will set willLeave to true. But React 18 batch update logic prevents willLeave from being set to true at the time handleAnimationEnd fires. This since state.willLeave is false, handleAnimationEnd fails to setState visible to false, causing the context menu to remain visible.

I've attached my patch-package that I used to fix the problem on my system. react-contexify+5.0.0.zip

By the way just for the record, I'm upset that the React developers chose to force the concept of batched updates on us. I have had to fight a number of issues, each of them not obvious, both in my own code plus a variety of third-party packages because of this. This has been very costly.

Thanks alot for identifying the issue, I'll test it out your patch when I'll get back to my workstation

kyro95 avatar Oct 21 '22 07:10 kyro95

Hey @ sotarules, thanks for the detailed write-up. The library has not been updated for a while, lack of time, covid, new kids, etc... Anyway, I'm currently working on the next version scheduled for this month. I'm trying to see if I can fix the issue without relying on flushSync if not then I'll go for it

fkhadra avatar Nov 03 '22 07:11 fkhadra