@tbinna We managed a workaround for our plugin using inherit as value for our outer-most HTML background instead of using the surface detection of background: var-(--ds-elevation-surface-current).
It is a workaround that worked for us in both issue panel, dialog, and page display. Not ideal, but gets the job done. I hope this discrepancy in background color gets fixed.
@DanielDelCore @MitchGavan, I’m trying my luck here one more time. Surface detection has been working and then broke again. It’s now broken for at least the past month. This is a production issue. I expect more urgency in fixing this or at least some comms if we have to resort to workarounds.
Hey @tbinna, sorry for the delay!
I suspect this may be a CSP issue, could you check the console of your app and let me know if there are any errors relating to surface detection?
Also, could you verify if updating your CSP config to include the following resolves the issue?
Content-Security-Policy: style-src connect-cdn.atl-paas.net
Cheers.
Thanks for your reply @DanielDelCore. I believe you are correct that this is a CSP issue. Have been fiddling with our CSP policy, but the suggested CSP does not work (we have a Connect app).
I am still trying to figure out how the CSPs apply here. We get the error below:
Refused to load the stylesheet 'https://connect-cdn.atl-paas.net/surfaces.css' because it violates the following Content Security Policy directive: "style-src 'self' 'unsafe-inline'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
Interestingly, the CSP violation error message in the browser console does not show the style-src CSP that we have configured (missing connect-cdn.atl-paas.net). I do not understand yet why that is.
I have tried both with and without style-src-elem (without, it should fallback to style-src), but neither works.
Update:
After some more research, I am unsure if the current approach is workable. This question seems to refer to a similar setup, and the answer is generally that this does not work.
Does Atlassian have a Connect example that demonstrates that this approach is working including a CSP that’s compliant with the Connect security requirements?
Hi @tbinna ,
A CSP policy for connect that works for us is:
"style-src": ["'self'", "'unsafe-inline'", "https://*.atl-paas.net"],
Unfortunately the unsafe-inline is needed, because all.js inlines the css for theming etc. dynamically.
It seems I got sidetracked and took the CSP error failing to load surfaces.css from an Atlassian background script for our own 
So, back to square one. The issue seems to be with the surface detection itself.
Below is the screenshot from Automation for Jira. They are using the approach suggested by @MitchGavan, which we are using too, but that does not work anymore and does not resolve to the correct background color.
As @Archer suggested, using background-color: inherit seems to work though.
@DanielDelCore is inherit the way to go? I believe the issue is not yet resolved.
Update:
I just noticed this again and wanted to highlight that this issue only exists if you view an issue on the board (clicking an issue opens a modal). It works correctly on /browser/<issue-key>. The general assumption seems to be that modal dialogs always have a darker background color shade. However, this should not be the case if you view an issue in the context of a dialog.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
@tbinna background: inherit;, surprisingly works! TIL. I’ve verified that on my side as well. If that’s the case, we can probably make that recommendation moving forward. Are there any known edge-cases between browsers for example that we should be aware of?
Hello,
We fixed the dark mode problems by overwriting the elevation-surface tokens based on the elevation inside our css reset files and then using these tokens when styling our components:
html {
--ds-elevation-surface-current: var(--ds-surface) !important;
--ds-elevation-surface-hovered: var(--ds-surface-hovered) !important;
--ds-elevation-surface-pressed: var(--ds-surface-pressed) !important;
}
html[data-surface="overlay"] {
--ds-elevation-surface-current: var(--ds-surface-overlay) !important;
--ds-elevation-surface-hovered: var(--ds-surface-overlay-hovered) !important;
--ds-elevation-surface-pressed: var(--ds-surface-overlay-pressed) !important;
}
html[data-surface="raised"] {
--ds-elevation-surface-current: var(--ds-surface-raised) !important;
--ds-elevation-surface-hovered: var(--ds-surface-raised-hovered) !important;
--ds-elevation-surface-pressed: var(--ds-surface-raised-pressed) !important;
}
html[data-surface="sunken"] {
--ds-elevation-surface-current: var(--ds-surface-sunken) !important;
--ds-elevation-surface-hovered: var(--ds-surface-sunken-hovered) !important;
--ds-elevation-surface-pressed: var(--ds-surface-sunken-pressed) !important;
}
Greetings
Max
It might be worth updating the documentation at https://atlassian.design/components/tokens/code#get-the-current-suface-color.