Open liangd407 opened 6 years ago
See #30
Instead of asking users to bypass the issue with pointer-events: none
on dragging, why not just set pointer-events to none directly in the library. After all, this is how split.js.org
implements the drag and I didn't even notice this was an issue until I switched to this library.
I totally agree with @lijunsong. @tomkp This is my story: I apply method from https://github.com/tomkp/react-split-pane/issues/30#issuecomment-278774489 to resolve a similar problem in 2018 October. This morning (August 2020), I faced the exact same issue 2 years ago (in a different repo forked from the repo in 2018). It took me 30 minutes to figure the root cause then apply the patch.
In 2018, I have something like this
<SplitPane
split="vertical"
size="360px"
pane2Style={{
pointerEvents: isDragging ? 'none' : 'auto',
}}
onDragStarted={() => { this.setState({ isDragging: true }); }}
onDragFinished={() => { this.setState({ isDragging: false }); }}
>
{/* Left Pane */}
<div>
Something
</div>
{/* Right Pane */}
<div>
<iframe />
</div>
</SplitPane>
It worked since my iframe
was in the right side (I used pane2Style
). And in 2020, my iframe
is in the left side🙈. I didn't notice that, something like this:
<SplitPane
split="vertical"
size="360px"
pane2Style={{
pointerEvents: isDragging ? 'none' : 'auto',
}}
onDragStarted={() => { this.setState({ isDragging: true }); }}
onDragFinished={() => { this.setState({ isDragging: false }); }}
>
{/* Left Pane */}
<div>
<iframe />
</div>
{/* Right Pane */}
<div>
Another div
</div>
</SplitPane>
I have to change pane2Style
to pane1Style
, or add both if I don't want to see this issue in the future. I think the best way to avoid this issue is to add pointer-events
itself in the library. What do you think? If that's good. I can make a PR. Thanks
good
O(∩_∩)O哈哈~信已收到,
how to handle the problem: element in pane2 has a iframe ?