[Security Solution][THI] - remove usages of EUI tint, shade and transparentize functions

[PhilippeOberti]

Summary

This PR is part of a list of PRs to perform the changes necessary to get the new Borealis theme working correctly. It focuses on removing the shade(), tint(), shadeOrTint(), tintOrShade() and transparentize() functions.

2 places have been impacted:

• the expandable flyout preview shadow

Light

before	after

Dark

before	after

• the unified data table
  • for row hover background color (I tried a few options here, this change is the one that looked the best to me, despite being identical color to the odd row background... I'm opened to suggestions here!)

Light

before	after

Dark

before	after

• for row comparison

Light

before	after

Dark

before	after

Notes: one usage of the transparentize function was left untouched here. This is a custom OverlayMask and this code replicates what's being done in the EUI codebase. I checked and EUI is still using the transparentize method with that color, so I figured I would keep this untouched for now...

#201888

[elasticmachine]

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

[kertal]

the unified data table
for row hover background color (I tried a few options here, this one for the one that looked the best, despite being identical color to the odd row background... I'm opened to suggestions here!)

adding @l-suarez to have a look at this, thx 🙏

[davismcphee]

I checked this out quickly today and agree we should get some design input for the table row hover styles. Using the same colour for both row striping and hovering makes the hovered row blend in more and less easy to identify in wider tables, but I'm not sure of an alternative without using tintOrShade. I'll ask the EUI team to take a look in Slack too in case they have ideas.

For reference, I tried out $euiColorLightShade for hovering too, but it seemed pretty harsh compared to before IMO.

Using tintOrShade (current):

Using $euiColorLightShade:

[MichaelMarcialis]

I checked this out quickly today and agree we should get some design input for the table row hover styles. Using the same colour for both row striping and hovering makes the hovered row blend in more and less easy to identify in wider tables, but I'm not sure of an alternative without using tintOrShade. I'll ask the EUI team to take a look in Slack too in case they have ideas.

@davismcphee: In case it helps, I think data grid row hover would call for using euiTheme.colors.backgroundBaseInteractiveHover. However, I would assume this style would be packaged with the EUI component, rather than something that requires separate styles.

[davismcphee]

@PhilippeOberti I hope you don't mind, I merged main and pushed a commit to adjust Unified Data Table to use $euiColorBackgroundBaseInteractiveHover.

@MichaelMarcialis Thanks for the hint. I was chatting with EUI folks earlier and they pointed me in a similar direction too, so I gave it a shot. For context, the issue was that for Amsterdam we have an override since the default data grid styles use a yellow highlight that we didn't want (I'm guessing since it conflicts with our "expanded" row styles). The hover styles have been changed in Borealis, but I believe we're supposed to maintain support for both Amsterdam and Borealis in main for now, so it was tricky to find an override that works for both.

I pushed a change to use $euiColorBackgroundBaseInteractiveHover for both Amsterdam and Borealis (already the default there), which still changes the colour in Amsterdam a bit, but it looks better than $euiColorLightShade at least. If this seems ok from the design side, I'm good to move forward with it and eventually remove the override entirely once Amsterdam is retired. WDYT?

[davismcphee]

Looks like CI is green now so I'm gonna approve from the Data Discovery side since I'm good with the current row hover override until we can remove it when Amsterdam is retired 👍

[mgadewoll]

✅ Changes LGTM from EUI side

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: e8bdf8c

Failed CI Steps

• :pipeline:🪄 Run Dynamic Pipeline: .buildkite/scripts/pipelines/pull_request/pipeline.sh

History

• 💚 Build #266134 succeeded 60d30b3
• 💛 Build #264944 was flaky fcf58f8
• 💔 Build #264585 failed fb383d6
• 💔 Build #263209 failed 75d0e50

[PhilippeOberti]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation