I tested my application as a standalone desktop app and there are no issues however upon transferring to the browser this problem began:
In order to adjust the size of the split panes the mouse cursor has to stay within the bounds of the split.
To replicate:
1. press and hold the left mouse button on the grey bar of the SplitPane to initiate a drag event in order to resize
2. whilst keeping the left mouse button held down move the mouse to the left or right of the split pane, keeping the mouse cursor within the bounds of the applet but outside of the bounds of the split
The consequence of the above is that the drag event is not applied to the grey bar of the SplitPane but to the panel on the left or right (depending which way the user drags) of the split.
I'm not sure if it's worth noting but the cpu is at full capacity during the drag event, I have assumed rightly or wrongly that this is to render as many adjustments as possible whilst dragging and considered the problem may be that it is trying to draw every frame and therefore unable to keep up with the mouse. I'm by no means saying it is this but maybe it will aid understanding of the issue.
See attachment for a screen recording of the issue - I move the mouse very slowly at the beginning, keeping the cursor within the bounds of the grey split bar, and correct control behaviour can be seen. After this I speed up the mouse movement and the drag event can be seen to be transferred on the left hand panel. In the video it may also be noted that the drag event that is transferred to the left hand pane is rather odd whereby the schematic rendered 'jumps' from 1 position to another - I suspect this is a separate bug but hopefully would go away if the drag event wasn't transferred incorrectly.
In order to adjust the size of the split panes the mouse cursor has to stay within the bounds of the split.
To replicate:
1. press and hold the left mouse button on the grey bar of the SplitPane to initiate a drag event in order to resize
2. whilst keeping the left mouse button held down move the mouse to the left or right of the split pane, keeping the mouse cursor within the bounds of the applet but outside of the bounds of the split
The consequence of the above is that the drag event is not applied to the grey bar of the SplitPane but to the panel on the left or right (depending which way the user drags) of the split.
I'm not sure if it's worth noting but the cpu is at full capacity during the drag event, I have assumed rightly or wrongly that this is to render as many adjustments as possible whilst dragging and considered the problem may be that it is trying to draw every frame and therefore unable to keep up with the mouse. I'm by no means saying it is this but maybe it will aid understanding of the issue.
See attachment for a screen recording of the issue - I move the mouse very slowly at the beginning, keeping the cursor within the bounds of the grey split bar, and correct control behaviour can be seen. After this I speed up the mouse movement and the drag event can be seen to be transferred on the left hand panel. In the video it may also be noted that the drag event that is transferred to the left hand pane is rather odd whereby the schematic rendered 'jumps' from 1 position to another - I suspect this is a separate bug but hopefully would go away if the drag event wasn't transferred incorrectly.