Magnify tool not working for all elements when added and it breaks

[kuehlc]

Prerequisites

• Which version are you using? (Is it latest?)
  Latest
• Are you reporting to the correct repository?
  Yes
• Did you search existing issues? (Were any related?)
  Yes. None looked related.

Description

I have tested adding/enabling tools that I want to work on up to 4 images at a time. Pan, zoom, and wwwc tool seem to work fine on each element when added, but the magnify tool only works (appears, but does not work properly) for a single element.

Steps to Reproduce the issue

1. When I do X
   Right click on second element
2. Then Y
   Drag mouse
3. I see behavior Z
   Magnify glass shows up on first element, but it does not cover properly. It gets locked to part of the first image, and it does not let you move the magnifying glass over the entire area that it should be enabled for.

Expected behavior: (What you expected to happen)
Magnify tool to work for each individual element when it is added globally.
Actual behavior: (What actually happened)
Magnify only works (appears, but does not work properly) on one element. When trying to use it on second element, it appears on the first element instead.

CodeSandbox With Reproduction of Issue:

https://codesandbox.io/s/nervous-chebyshev-nfz39

• Basic Template

[kuehlc]

@dannyrb or anyone, Have you gotten a chance to look into this yet? I don't mean to rush anyone if it's already being worked on. I just wasn't sure if it has been seen since it has been up for a few days. I don't know what the expected turnaround time for these should be since it is open source.

[jlopes90]

I already found a solution.

.cornerstone-element {
  position: relative;
}

[kuehlc]

@jlopes90 that makes it work for when you have more than one image for it to work on?

[kuehlc]

@jlopes90 I'll try it, but even if that works, it seems like a bug that you need to add that type of styling. It should work by default like the others do.

[dannyrb]

@kuehlc, does that do the trick for you? We could inline the style on the dynamically created element; I believe we don't because we don't want it to interfere with any user defined styles.

[kuehlc]

@dannyrb yes, the style change made it work. It just seems like a bug because the other tools work by default for this. I don't see how the same thing for those tools can't be done for magnify, but you know the code better than me.

[dannyrb]

@kuehlc, that's a good point. I wouldn't be against a PR that adds the appropriate style a la JS when the magnifying glass should be visible.

[kuehlc]

I don't have time to do the PR myself due to a deadline that I'm on for a current project, but I agree that this would be a nice add. Thanks in advance for whoever commits it.

[web2ls]

I have like a same problem with magnify (i work with a four viewports)
steps to reproduce:

• select magnify tool
• working with tool in a one of viewport (on this step all work correctly)
• switching to Move tool
• try Move in the previous viewport
• magnify tool is still working and on the background moving the basic image

after this steps i have incorrect behavior for other viewports for the Move tool

This behavior i can get for the version in master branch and on the OHIF demo site version

[dannyrb]

Magnify tool appears to have another (potentially related) issue where each "click" creates a new enabled element. This causes ~22 tools to be duplicated when the sync flag is set (you can see this at cornerstoneTools.store.state.tools).

I'm wondering if listeners / elements aren't being properly cleaned up in some scenarios. I think the issue may be that we need to shift the clean-up from framework lifecycle events to registrations in the create/add. (mouseup should always fire, but our framework's postmousedown may not)

[web2ls]

oh yeah, i saw this problem with creating additional elements
sorry, i forget write about this in my message

[JamesAPetts]

Believe this is resolved in 4.19.1, would be great if y'all could check!