Fix 19570 tree chart not compliant strict csp styles

[Manviel]

Brief Information

This pull request is in the type of:

• bug fixing.
• refactoring.

What does this PR do?

This pull request addresses a specific limitation concerning Content Security Policy (CSP). When CSP is enabled, direct assignments to an element's style property using a string are disallowed. However it is possible to use className instead.

Basically, innerHTML causes the violation because it inserts html that contains inline styles.

Fixed issues

Tree chart with tooltips is not compliant with strict CSP directives for styles

Details

Before: What was the problem?

CSP violation errors are thrown into browser console:

After: How does it behave after the fixing?

It no longer uses inline styles.

Document Info

One of the following should be checked.

• This PR doesn't relate to document changes

ZRender Changes

• No.

Others

Tried to apply a similar solution as in ecomfe/zrender#1030

[echarts-bot]

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

To reviewers: If this PR is going to be described in the changelog in the future release, please make sure this PR has one of the following labels: PR: doc ready, PR: awaiting doc, PR: doc unchanged

This message is shown because the PR description doesn't contain the document related template.

[Manviel]

Enabling a strict policy for the style-src directive in CSP offers several security benefits for your web application:

• XSS attacks aim to inject malicious scripts into your website. By restricting stylesheet sources, you prevent attackers from embedding malicious code within stylesheets and potentially compromising user data or website functionality.
• A strict policy grants you more control over the styles applied to your website. You determine the legitimate sources for stylesheets, preventing unauthorized styles from altering your website's appearance or behavior.

[mmerezhko-hv]

styles properties that are set directly on the element's style property will not be blocked, allowing users to safely manipulate styles via JavaScript. e.g. this, document.body.style.background = 'green'; won't cause an unsafe-inline violation.

[Manviel]

Hello @Ovilia ,
Could you review this PR or help me find the right person?

[mmerezhko-hv]

styles properties that are set directly on the element's style property will not be blocked, allowing users to safely manipulate styles via JavaScript. e.g. this, document.body.style.background = 'green'; won't cause an unsafe-inline violation.

[admsev]

@gooroodev review

[gooroodev]

Summary of Changes

1. ESLint Configuration:

   • Updated tsconfig.json path to include all subdirectories.
   • Added browser environment.

2. Tooltip Component:

   • Refactored assembleArrow function to use CSS classes instead of inline styles.
   • Introduced helper functions calculateArrowOffset and getColorClassName.
   • Refactored setContent method to use helper functions clearContent, setTextContent, and appendArrow.

3. Tooltip Markup:

   • Removed inline styles and replaced them with CSS classes.
   • Refactored getTooltipTextStyle to return CSS class names instead of inline styles.
   • Refactored wrapBlockHTML, wrapInlineNameHTML, and wrapInlineValueHTML to use CSS classes.

4. Format Utility:

   • Updated getTooltipMarker to use CSS classes instead of inline styles.

5. Test HTML Files:

   • Added basic.css file to include necessary styles.
   • Added Content-Security-Policy meta tag to enforce strict CSP.
   • Removed inline styles and replaced them with styles from basic.css.

6. CSS File:

   • Created basic.css with necessary styles for tooltips, markers, and layout.

Issues, Bugs, and Typos

1. Code Duplication:

   • calculateArrowOffset and getColorClassName functions are defined inside assembleArrow. They can be moved outside for better readability and reusability.

2. Inconsistent CSS Class Naming:

   • The class names for colors and other properties are inconsistent. Consider using a consistent naming convention for better maintainability.

3. Unused Imports:

   • Ensure no unused imports or variables are present in the updated files.

Proposed Code Improvements

1. Move Helper Functions Outside:

   function calculateArrowOffset(rotatedWH: number, borderWidth: number, arrowWH: number) {
       return Math.round(
           (
               ((rotatedWH - Math.SQRT2 * borderWidth) / 2
                   + Math.SQRT2 * borderWidth
                   - (rotatedWH - arrowWH) / 2)
               * 100
           ) / 100
       );
   }
   
   function getColorClassName(color: ZRColor) {
       const colorValue = convertToColorString(color);
       return colorValue.replace(/[^a-zA-Z0-9]/g, '');
   }

2. Consistent CSS Class Naming:

   • Ensure that the class names follow a consistent pattern, e.g., tooltip-arrow-color-fff instead of tooltip-arrow-background-color-fff.

General Review of Code Quality and Style

1. Code Quality:

   • The refactoring improves the separation of concerns by moving styles to CSS classes.
   • The use of helper functions enhances code readability and maintainability.
   • The use of CSS classes instead of inline styles makes the code more compliant with CSP.

2. Code Style:

   • The code follows good practices such as modularization and reusability.
   • The naming conventions for variables and functions are clear and descriptive.
   • The indentation and formatting are consistent and adhere to standard coding guidelines.

3. Testing:

   • Ensure that all changes are covered by existing or new tests.
   • Verify that the changes do not introduce any regressions or new issues.

Overall, the pull request significantly improves the compliance with strict CSP by removing inline styles and using CSS classes. The proposed changes enhance the maintainability and readability of the code.

Yours, Gooroo.dev. To receive reviews automatically, install Github App