Batch operations leading to incorrect dimension information

[GriffinBaxter]

Environment info

• Cytoscape.js version : 3.23.0 (has been reproduced in 3.30.3 too)

• Browser/Node.js & version : Chrome + other browsers, Node 20.12.5

• cytoscape-expand-collapse version : 3.2.1 (has been reproduced in 4.1.1 too)

Current (buggy) behaviour

What does the bug do?

We're using cytoscape-expand-collapse and compound nodes. Yes, this is a plugin but the problem seems to lie in cytoscape itself (not the plugin).

We need to expand all compound nodes so that potentially hidden nodes can be updated.

Our current process is:

• Expand all compound nodes.
• Apply node updates and styling to all relevant nodes (the positions of some nodes may change as part of this update).
• Collapse compound nodes that were previously collapsed.

This works but the canvas is updated multiple times and the image flickers due to all the updates.

Desired behaviour

What do you expect Cytoscape.js to do instead?

Ideally, we'd like to use the batch operation to prevent the canvas redrawing when all the compound nodes are temporarily expanded. We'd also like to use the batch operation to improve performance for a large number of nodes if possible. However, currently when we use the batch operation the collapsed compound nodes end up with the incorrect x/y position. I believe this is due to the limitation where a node's dimensions are not updated during the batch operation (https://js.cytoscape.org/#cy.batch). Is there any way that we can perform the above steps where Cytoscape only does one render and the positions of the collapsed nodes are correct?

Minimum steps to reproduce

What do you need to do to reproduce the issue?

Fork/clone this JSBin demo and reproduce your issue so that your issue can be addressed quickly and effectively:
http://jsbin.com/fiqugiq

N/A, cannot share proprietary code and don't have a minimum reproduction (sorry).

For reviewers

Reviewers should ensure that the following tasks are carried out for incorporated issues:

• Ensure that the reporter has included a reproducible demo. They can easily fork this JSBin demo: http://jsbin.com/fiqugiq
• The issue has been associated with a corresponding milestone.
• The commits have been incorporated into the corresponding branches. Bug-fix patches go on
  • master,
  • unstable, and
  • the previous feature release branch (e.g. 1.1.x if the current release is 1.2).
• The issue has been labelled as a bug, if necessary.

[maxkfranz]

N/A, cannot share proprietary code and don't have a minimum reproduction (sorry).

Without a minimal demo to reproduce your issue, there's no way to verify whether this is actually a bug in the library — or whether you've a bug in your app itself.