Camunda-modeler: Cursor Not Reset after Showing Not Allowed

Created on 23 May 2019  路  16Comments  路  Source: camunda/camunda-modeler

__Describe the Bug__

Cursor behavior changing while connecting tasks module using arrow option.

When 2 objects are close and trying to connected the flow using arrow icon available from object tool bar. After mouse release inside another object also, cursor icon not changed from not-allowed mode to default mode.End user felt that its not allowed to add text or do other activities. Its changing only after the arrow icon from object tool tip.

Please find the attachment video for more clarity.
May 23 2019 12_52 PM.zip

__Steps to Reproduce__

Steps to reproduce the behavior: cf. video above

  1. Start creating a connection between to close elements
  2. Drag the connection to target in a very quick manner

Hint: This does not occur every time, but in certain situations

__Expected Behavior__

not-allowed cursor should be removed when the connection is allowed.

__Environment__

Please complete the following information:

  • OS: [Windows 10]

    • Camunda Modeler Version: [3.*]

__Additional Context__

  • dragging.out -> connect.out is not fired in certain situations, so the connect-not-ok marker is not cleaned up properly from bpmn:Process element.

Related to SUPPORT-6128
Related to SUPPORT-6143

bug support ux

All 16 comments

Not an issue anymore?

Hi Nikku, Thanks for reopening the issue, I proposed my solutions and given merge request. I expect your team to validate and merge the code.

https://github.com/camunda/camunda-modeler/pull/1387

We should check, if we can reliably reproduce this. I could observe this a few times, too, though not with a clear path to reproduce.

I also experienced this a couple of times ago. I'll try to find a reproducible path.

Please refer code for the fix..
Pull request
https://github.com/camunda/camunda-modeler/pull/1387

@RamjiRamachandran can you also verify whether the bug is still present on your environment with the latest nightly build?

Regarding the bug described in the video, I was able to reproduce it on current nightly:

Jun-25-2019 14-00-56

It sets the connect-not-ok marker to the root element and never does a clean-up. We have several scenarios, where it looks like events got fired too quickly and the marker cleanup will simply be skipped. dragging.out, connect.out and connect.cleanup is not fired for the root element for some reason.

Is it a regression? Can you reproduce it in v3.1.x, too?

Yes I can reproduce it on v3.1.x and also on v3.0.0.

So, let's conclude: As it's not a regression, let's postpone this for the moment.

It's also very hard to create a test case for this since the problem seems to be caused by a missing fired dragging.out event when the cursor leaves the bpmn:Process elements, which results in a missing cleanup of the connect-not-ok marker.

@RamjiRamachandran we are still open for external contribution which fixes the situation in diagram-js (cf. it's not correctly cleaning up, since dragging.out --> connect.out is not fired).

I updated the issue description to fill the expectations.

This may be related to https://github.com/bpmn-io/bpmn-js/issues/1123.

It seems like recent versions of Chrome are more likely to swallow the hover event.

Related to SUPPORT-6143

After another try of debugging the root cause, it reveals also the svg node native mouseout event isn't thrown, which leads to the opinion it depends on the browser that sometimes, on fast interactions, some events are not thrown.

After an internal discussion, we should go for cleaning up cursor states in a proper way, since we can NOT guarantee all events are always fired properly. This is quite a similar problem with the HoverFix

Was this page helpful?
0 / 5 - 0 ratings