[IGN-9406] Scroll-bar/Overflow Frustrations on Perspective View Canvas

Ignition
,
1

Hi All,

I've opened a support ticket about this, but I thought I would also post this to the forum community (and the resident CSS wizards!) because this seems like an interesting problem

Ignition: 8.1.32
Browser: Chrome 122.0.6261.95

I have an X-Y coord (fixed) container with an image component and a view canvas overlaid on it. The image component displays an SVG background image for a plant operation and the view canvas displays instances of plant data points. In this example, the instances are essentially arrows that show conveyor status and direction. When a user hovers over any instance a style called "x2" (defined in stylesheet.cs) transforms the arrow, essentially magnifying it by 200%.

x2 style class 
.psc-x2 { transition: all .2s ease-in-out; }
.psc-x2:hover { transform: scale(2) !important;  z-index: 5;}

Problem:

When the user hovers over these arrows in the client and the symbol magnifies, the client adds horiz and vert scroll-bars.

image
image

This occurs even though, for each instance in the view canvas, the style prop has overflow: hidden as an attribute, as does the root container of the embedded view definition.

If I drop instances of this view as "loose" embedded views onto a view (ie not in a view canvas), then these scroll bars do not appear when the "x2" style hover transform is activated. The embedded view behaves properly.

If I inspect the browser dev tools in Chrome and dig into the view canvas div element, I can see that there is an overflow: auto attribute added that would explain the scroll-bars on magnify, but I have no idea where this attribute is coming from. You can see in the screenshot below that the position, height, width, top, left, bottom, and right attributes from the instance props match the instance div in the browser, but the overflow: hidden in the instance style prop is applied one layer "down" in a child div element.

image
image1917×800 93.4 KB

So, the million dollar question is: where does the overflow: auto come from? - and is there any way to override this at runtime, either by css injection on the view canvas component, or in the stylesheet.css file?

2

You're setting overflow for the instance, but not the underlying View being instanced.

In theory, there may be situations where Views allow for overflow:visible, but a View Canvas may want to prevent that behavior. Consider modifying the View (and/or the Coordinate Container) being instanced to have an overflow of "hidden".

3

So I've tried setting the underlying view's root container (flex-row) overflow to both hidden and visible, but it doesn't affect that phantom overflow: auto that I see in the browser dev tools, nor does either get rid of those unwanted scroll-bars.

4

In your screenshot, the View being instanced is a Coordinate Container - so the call-out of "flex-row" raises warning flags.

5

You're right, I misspoke. I added a second layer of embedding to try and troubleshoot this. So the view in the view canvas instances is a coord container (with padding) around an embedded view, which itself is a flex-row container.

6

In any case, setting the overflow to visible or hidden on all root containers doesn't have any effect on the overflow: auto seen in my screenshot.

7

Here's what I found while trying to replicate once I had the rules in place in stylesheet.css, a Style named "x2", and an icon placed within a Coordinate Container, and the Style applied to the Icon...

As soon as I hovered over the Icon -> Scrollbars (Icon).
I specified the overflow of the Icon to be hidden.
I Hovered over the Icon again -> Scrollbars (Coordinate container).
I specified the overflow of the parent container (Coordinate) to be hidden.
I hovered over the Icon again -> No scrollbars.
I placed a View Canvas in another View, specified an instance should be of my View ("SVG"), and entered Preview mode.
I hovered over the View Canvas instance of my SVG View -> No scrollbars.

Nesting your Icon in a Container, then embedding that View by using an Embedded View within a flex layout View, and then instancing that flex layout View in a View Canvas is layers on layers of troubleshooting you don't want. Simplify, then try to replicate again. I've verified my recommendation works, and any successful replication on your end would likely point to an improper specification of overflow somewhere along your embedding/nesting structure.

I've attached a simplified project which should show this working as expected within the View View.
ViewCanvas.zip (8.3 KB)

2 Likes
8

Thanks for sending this test project. Your example does indeed not show scrollbars when embedded in a view canvas and hovered over.

I did expand upon your example and copied your "SVG" view into a new view called "SVG_1". The only difference on this view is that I set the root container and icon style properties to use overflow: visible rather than hidden, as this is actually the desired behavior for the hover style. (I know I used hidden in my OP, blame that on my lack of CSS knowledge).

I then added an instance to the view canvas of "SVG_1" and went into preview mode.
Hover over instance 0 (hidden) --> no scroll bars
Hover over instance 1 (visible) --> scroll bars
Change instance 1 style props to overflow: visible
Hover over instance 1 --> scroll bars

I then added an embedded view of SVG to View view
Hover over SVG --> no scroll-bars, cropped on hover
I then added an embedded view of SVG_1 to View view
Hover over SVG_1 --> no scroll-bars, not cropped on hover (desired behavior)

image
image600×600 27 KB

I then inspected all 4 of the above elements and highlighted the differences in the <div>s in the below screenshot. You can see that, in the view canvas instances, that there is an overflow: auto attribute added that is not accounted for in the instance properties or the embedded view definitions themselves.

image
image1920×768 118 KB

From the side-by-side comparisons, you can see that this overflow: auto that is somehow inserted into the view canvas instances is causing the unwanted scroll-bars and, for my use case, is making the view canvas unusable.

Attaching my modified project from your example.
ViewCanvas_2024-03-08_1754.zip (24.5 KB)

9

Ah, I see the issue now.

Bad news:
Yep, it appears to be a bug, in that we're applying ViewCanvas.props.instances[X].style.overflow to the container which is the root of the instanced View instead of properly applying that overflow to the wrapping <div>.

Good news:
I have a one-off workaround. Apply a domId property to the META category of your ViewCanvas, and supply some unique value ("MyViewCanvas" in the upcoming example). Now modify your stylesheet a bit:

div#MyViewCanvas > div {
	overflow: visible !important;
}

.psc-x2 { transition: all .2s ease-in-out; }
.psc-x2:hover { transform: scale(2) !important;  z-index: 5;}

This rule will only be applied to this View Canvas, so you mileage may vary. If you need it to apply elsewhere, you can either add a new targeted rule, or lossen up the locator I've supplied.

2 Likes
10

I've opened an internal ticket to get this resolved, though we are absolutely slammed and I am unable to provide any sort of estimate on when it would indeed be picked and resolved.

2 Likes
11

This did the trick. I will go ahead and mark this as a solution, even if it is just a work-around. Saved me from having to stumble upon the workaround myself. Thank you!!

image

2 Likes
12

Oh, could I get the support ticket number please? I'll attempt to update that as well while I'm on it.

13

https://support.inductiveautomation.com/hc/en-us/requests/107838