Forums Home / Wijmo / General Discussion
Posted by: omarovd on 1 October 2024, 4:15 pm EST
omarovd
Posted 1 October 2024, 4:15 pm EST - Updated 1 October 2024, 4:20 pm EST
Hi folks!
We are migrating our project to React 18 and started using wijmo package 5.20221.842 version.
We have strict content policy applied (no inline styles) but for the components, where FlexGrid is presented - we face error about violation of the policy (pls see attachment) (that happens, once we destroy parent component).
Is there a possibility to prevent FlexGrid emit inline styles?
akshay.rajput
Posted 4 October 2024, 5:13 am EST
Hi Dulat,
Apologies for the inconvenience!
Unfortunately, this is a limitation of the product. Wijmo does not comply with the style-src Content Security Policy as it uses inline CSS for applying style to many of it’s controls. However, it does support the script-src policy so if you are using the default-src policy or style-src policy, I would suggest you to just use script-src as default-src policy includes style-src.
omarovd
Posted 4 October 2024, 4:24 pm EST
Out of curiosity: why flexGrid requires to apply style (in particular - width size) at it destroy moment? Only this behavior triggers our security-watchdog to report policy violation. It is flexGrid destroy process, isn’t it? What is the benefit or convenience it provides, if at next discreet of time flexGrid disappears?
akshay.rajput
Posted 7 October 2024, 3:15 am EST
Hi Dulat,
The inline CSS used in Flex Grid is applied at the time of rendering. I am not sure why is this error being thrown in your application at the time when the grid is destroyed I would require a runnable sample from you so I can investigate further on this. In my testing, the issue occurs when the grid is initialized. This variation might be occurring due to different environment specifications.
Please refer to the following sample application: https://stackblitz.com/edit/react-wepabm-sxaqez?file=index.html
The style-src rule suggests not to define styles on the style attribute of elements or style tag under html. In the Wijmo source code style attribute related operations are extensively used and many Framework/Libraries/UI Tools like Tailwind, which is currently the most popular CSS tool on the market, follow the same approach. At the moment, It is very difficult us to meet this style-src rule as it would be a huge task.
I would suggest you to allow inline CSS in your CSP header(see the above shared sample link).
omarovd
Posted 7 October 2024, 12:42 pm EST - Updated 7 October 2024, 12:47 pm EST
Hi!
Here is the problematic spot in our case:
As you can see on the screenshot - at the moment of the control disposing - it applies the width size.
akshay.rajput
Posted 8 October 2024, 8:43 am EST
Hi Dulat,
I tried to reproduce your issue at my end but it seems that on destroy the setAttribute for ‘style’ was only called when I set inline style for grid but that is not a valid use case for your scenario, so I am not sure how to reproduce this issue. Please share the modified sample reproducing the issue so we can get back to you accordingly.
As for why are using setAttribute function in the Dispose method… I am not really sure which is why I have escalated this case to the development team to get their input on the same[WJM-35098]. I will get back to you once I have any updates on the same.
In any case, since style-src content security policy is not supported in Wijmo, I would suggest you to not use it on pages using Wijmo.
akshay.rajput
Posted 11 October 2024, 2:41 am EST
Hi Dulat,
I have an update from the development team. As I discussed with the development team, on dispose it’s important to return the DOM element (the host element) to its original state before the control is removed. This ensures that the element stays intact and doesn’t lose any attributes or get altered after the control is disposed of.
Applying original element properties on dispose makes sure the element has returned to it’s original state and can be used again to create the grid or perform other logical tasks.
I hope this clears up any confusion.
Regards,
Akshay
omarovd
Posted 11 October 2024, 10:29 am EST - Updated 11 October 2024, 10:49 am EST
Hi Akshay!
Actually, this answer leads to next questions:
Usually default properties are applied in the constructor. What if I need few Grids on the page? Does that mean, without calling “dispose” process on the wijmo source-control, I’ll receive a grid’s instance for my 2-nd component not in default shape?
Question 2:
The exercise with returning wijmo control in original shape means: once created, it is ready to be reused at any moment, isn’t it? But what if I don’t need it anymore? Is it not a direct sign of memory leak, if there are unused objects in the memory, accumulating and consuming more and more limited space?
It would be something deserving attention: the CSP complains only on dispose cycle of the wijmo control. All other control’s lifecycle methods (including animation) work safely. Maybe it worth to revise logic of dispose and tune it to be compliant with other methods? Or provide method to manage it from outside?
On the same note - this problem didn’t exist on the 2021 version of the wijmo products
akshay.rajput
Posted 15 October 2024, 2:42 am EST
Hi Dulat,
>> Usually default properties are applied in the constructor. What if I need few Grids on the page? Does that mean, without calling “dispose” process on the wijmo source-control, I’ll receive a grid’s instance for my 2-nd component not in default shape?
You can add multiple grids in a single page without this being an issue. The original attributes of the grid are saved within the scope of the grid instance.
>> The exercise with returning wijmo control in original shape means: once created, it is ready to be reused at any moment, isn’t it? But what if I don’t need it anymore? Is it not a direct sign of memory leak, if there are unused objects in the memory, accumulating and consuming more and more limited space?
This is not the case. When I said ‘Applying original element properties on dispose makes sure the element has returned to it’s original state and can be used again to create the grid or perform other logical tasks.’ What we meant was, suppose you have an element in your html where you want to add the grid:
Example:
<div>
<div id="theGrid" style="max-height:400px"></div>
</div>
When we initialize the grid with say command:
var grid = new FlexGrid("theGrid",{...options});
This will save all the original attribtues of the element and add the grid to DOM, the element now:
<div>
<div id="theGrid" style="max-height:400px" class="wj-control wj-content wj-flexgrid" tabIndex="-1">
<div style="position: relative; left: 0px; top: 0px; width: 100%; height: 100%; overflow: hidden; min-width: inherit; min-height: inherit; max-width: inherit; max-height: inherit;">
...
</div>
</div>
</div>
Now If I dispose the grid the dispose method remove all handlers and clear the memory and additionally it sets the element in its original position, which is:
<div>
<div id="theGrid" style="max-height:400px"></div>
</div>
and not:
<div>
<div></div>
</div>
Now, the next time you create a grid you will start from the same original position of having an element as it was the first time the grid was created.
This does not accumulate memory or save any unused objects after the grid is disposed.
>> Maybe it worth to revise logic of dispose and tune it to be compliant with other methods? Or provide method to manage it from outside?
Please note that it is not just the dispose method the setAttribute call is used extensively in the Wijmo code for other purposes including print or using cell template, which is why we mark this as a limitation as a lot more work is required in order to have complains with the CSP style-src unsafe-inline policy. As of now this is a limitation of the product.
