Terminal has white borders in dark mode (Update ThemeUtils::SetWindowFrameDarkMode to use new DWM API) #4787

@DHowett-MSFT commented on GitHub (Nov 27, 2019):

Finally figured this out!

If we set the extended frame margins to {0}, we can fully suppress the white border. The cost, though, is that we have to paint our own accent color -- but only on the top of the window. The borders stay the same.

Accent On

Accent Off

Notice how the right border is visible, just dim. This looks like Chrome and Firefox as well.

@DHowett-MSFT commented on GitHub (Nov 27, 2019): Finally figured this out! If we set the extended frame margins to `{0}`, we can fully suppress the white border. The cost, though, is that we have to paint our own accent color -- but only on the _top_ of the window. The borders stay the same. ## Accent On ![image](https://user-images.githubusercontent.com/14316954/69697778-5e37a580-1098-11ea-9f36-feb95b258729.png) ## Accent Off ![image](https://user-images.githubusercontent.com/14316954/69697802-75769300-1098-11ea-9e07-c9f62a0230e9.png) Notice how the right border _is visible_, just dim. This looks like Chrome and Firefox as well.

claunia commented

@beviu commented on GitHub (Nov 27, 2019):

Maybe one way is to use DwmGetColorizationColor and WM_DWMCOLORIZATIONCOLORCHANGED to get the accent color and HKCU\Software\Microsoft\Windows\DWM\ColorPrevalence to detect if we need to put the accent color in the title bar or not. Last time I tried, watching for registry changes for this key didn't work in the app but worked in another Win32 project (so maybe because it's a store app? I don't really know how this works) so I couldn't make it update when you change the setting at runtime. So I abandoned this idea to draw the top border ourselves but looking back I think that it's not a big deal.

Also, note that the border's color is a little bit brighter than the title bar's color so the value from DwmGetColorizationColor needs to be modified. You can see a 1px border with lighter color than the title bar if you zoom in this screenshot and you look at the top and left of the window:

@beviu commented on GitHub (Nov 27, 2019): Maybe one way is to use `DwmGetColorizationColor` and `WM_DWMCOLORIZATIONCOLORCHANGED` to get the accent color and `HKCU\Software\Microsoft\Windows\DWM\ColorPrevalence` to detect if we need to put the accent color in the title bar or not. Last time I tried, watching for registry changes for this key didn't work in the app but worked in another Win32 project (so maybe because it's a store app? I don't really know how this works) so I couldn't make it update when you change the setting at runtime. So I abandoned this idea to draw the top border ourselves but looking back I think that it's not a big deal. Also, note that the border's color is a little bit brighter than the title bar's color so the value from `DwmGetColorizationColor` needs to be modified. You can see a 1px border with lighter color than the title bar if you zoom in this screenshot and you look at the top and left of the window: ![image](https://user-images.githubusercontent.com/56923875/69699033-3cb1da80-10e7-11ea-8cc1-128392fdda41.png)

claunia commented

@DHowett-MSFT commented on GitHub (Nov 28, 2019):

@greg904 we probably need both actually -- to listen to WM_DWMCOLORIZATIONCOLORCHANGED and to read ColorPrevalence. We shouldn't need to listen to the registry key directly, since it should be wrapped up in the WM.... Chromium seems to have an algorithm for figuring out the accent border color; perhaps there's something we can learn from it?

@DHowett-MSFT commented on GitHub (Nov 28, 2019): @greg904 we probably need _both_ actually -- to listen to `WM_DWMCOLORIZATIONCOLORCHANGED` _and_ to read `ColorPrevalence`. We shouldn't need to listen to the registry key directly, since it _should_ be wrapped up in the `WM...`. Chromium seems to have an algorithm for figuring out the accent border color; perhaps there's something we can learn from it?

claunia commented

@beviu commented on GitHub (Nov 28, 2019):

I would assume that WM_DWMCOLORIZATIONCOLORCHANGED is only sent when the accent changes (DwmGetColorizationColor) but not when the accent color on title bar and borders setting (ColorPrevalence) is toggled based on the name. But I need to check this. EDIT: I was wrong, it's also sent when that setting changes.

I found this from Chromium: af5c81b48f/chrome/browser/themes/theme_service_win.cc (L60)
af5c81b48f/chrome/browser/ui/views/frame/glass_browser_frame_view.cc (L609)

Note that the algorithm that Chromium uses isn't working correctly in 1809+ when ColorPrevalence is disabled: https://bugs.chromium.org/p/chromium/issues/detail?id=950362.

The top border has the accent color but it should not, it should be gray like the other left, right and bottom borders:

@beviu commented on GitHub (Nov 28, 2019): I would assume that `WM_DWMCOLORIZATIONCOLORCHANGED` is only sent when the accent changes (DwmGetColorizationColor) but not when the accent color on title bar and borders setting (ColorPrevalence) is toggled based on the name. But I need to check this. **EDIT**: I was wrong, it's also sent when that setting changes. I found this from Chromium: https://github.com/chromium/chromium/blob/af5c81b48faf773c19b7f3c495a1c0202f9c5b00/chrome/browser/themes/theme_service_win.cc#L60 https://github.com/chromium/chromium/blob/af5c81b48faf773c19b7f3c495a1c0202f9c5b00/chrome/browser/ui/views/frame/glass_browser_frame_view.cc#L609 Note that the algorithm that Chromium uses isn't working correctly in 1809+ when ColorPrevalence is disabled: https://bugs.chromium.org/p/chromium/issues/detail?id=950362. The top border has the accent color but it should not, it should be gray like the other left, right and bottom borders: ![image](https://user-images.githubusercontent.com/56923875/69827508-f6a86400-1217-11ea-8e24-5cb50105798f.png)

claunia commented

@lukeblevins commented on GitHub (Dec 1, 2019):

Not to get too off-topic here, but whichever method Microsoft Edge uses to draw the top border has the unintended consequence of mis-matching a transparent top border with the other 3 sides. This is visible only when the Windows theme is set to "dark" while the app theme is "light."

@lukeblevins commented on GitHub (Dec 1, 2019): Not to get too off-topic here, but whichever method Microsoft Edge uses to draw the top border has the unintended consequence of mis-matching a transparent top border with the other 3 sides. This is visible only when the Windows theme is set to "dark" while the app theme is "light." ![image](https://user-images.githubusercontent.com/20365014/69909815-b8a17080-13ce-11ea-9744-3b301c7f2963.png)

claunia commented

2026-01-30 23:56:33 +00:00

@Stanzilla commented on GitHub (Jan 13, 2020):

@DHowett-MSFT is a fix for this coming in the next release?

@Stanzilla commented on GitHub (Jan 13, 2020): @DHowett-MSFT is a fix for this coming in the next release?

claunia commented

@Piroro-hs commented on GitHub (Jan 13, 2020):

The terminal still shows a 1 pixel thin white border on the left of unfocused window in some cases. In my case, the border only appears when the screen scale is 125% and disappears after window resizing.

just after launch

resized

Windows 10 18362.535
Windows Terminal 0.7.3451.0

@Piroro-hs commented on GitHub (Jan 13, 2020): The terminal still shows a 1 pixel thin white border on the left of **unfocused** window in some cases. In my case, the border only appears when the screen scale is 125% and disappears after window resizing. just after launch ![](https://user-images.githubusercontent.com/22536104/70859601-c40da380-1f59-11ea-9f38-4cbdf6ba713f.JPG) resized ![](https://user-images.githubusercontent.com/22536104/70859612-f7e8c900-1f59-11ea-9f8e-0c0bb9b50b97.JPG) Windows 10 18362.535 Windows Terminal 0.7.3451.0

claunia commented

2026-01-30 23:56:33 +00:00

@DHowett-MSFT commented on GitHub (Jan 13, 2020):

@Stanzilla a fix will be coming for this bug in the release that comes after the bug is closed 😄

@DHowett-MSFT commented on GitHub (Jan 13, 2020): @Stanzilla a fix will be coming for this bug in the release that comes after the bug is closed :smile:

claunia commented

2026-01-30 23:56:33 +00:00

@gwojan commented on GitHub (Jan 14, 2020):

One thing I've just noticed is the white border is much more prominent on laptops with NVIDIA video adapters. I have three different Dell laptops and the one with AMD graphics the border is not nearly as noticeable. Does that make any sense at all?

All three laptops have Dark Mode enabled with Windows 10 1903.

@gwojan commented on GitHub (Jan 14, 2020): One thing I've just noticed is the white border is much more prominent on laptops with NVIDIA video adapters. I have three different Dell laptops and the one with AMD graphics the border is not nearly as noticeable. Does that make any sense at all? All three laptops have `Dark Mode` enabled with Windows 10 1903.

claunia commented

@spencerwooo commented on GitHub (Feb 5, 2020):

Can confirm on what @gwojan and @Piroro-hs reported. ThinkPad T460s with NVIDIA GeForce 930M on Windows 10 Pro 19041.21 with Windows Terminal (Preview) 0.8.10261.0. Screen resolution is 1920*1080 and the scale is set to 125%.

State	Screenshot
Just After Launch (in focus)
Just After Launch (out of focus)
After resize (in focus)
After resize (out of focus)

The left side white border is much more prominent than the other three when initially launched. After resizing the problem is gone.

@spencerwooo commented on GitHub (Feb 5, 2020): Can confirm on what @gwojan and @Piroro-hs reported. **ThinkPad T460s** with **NVIDIA GeForce 930M** on **Windows 10 Pro 19041.21** with **Windows Terminal (Preview) 0.8.10261.0**. Screen resolution is **1920*1080** and the scale is set to **125%**. |State|Screenshot| |:--:|:--:| |Just After Launch (in focus)|![](https://user-images.githubusercontent.com/32114380/73821071-14083880-482e-11ea-821f-9e76dab499c3.png)| |Just After Launch (out of focus)|![](https://user-images.githubusercontent.com/32114380/73821167-4dd93f00-482e-11ea-8501-5b2b404fa932.png)| |After resize (in focus)|![image](https://user-images.githubusercontent.com/32114380/73821520-1323d680-482f-11ea-8f89-fc6d67d625f2.png)| |After resize (out of focus)|![image](https://user-images.githubusercontent.com/32114380/73821561-25057980-482f-11ea-9f24-17cb51c1827c.png)| The left side white border is much more prominent than the other three when initially launched. After resizing the problem is gone.

claunia commented

@beviu commented on GitHub (Feb 20, 2020):

This issue should probably be split into two issues:

Terminal has white borders in dark mode
Update ThemeUtils::SetWindowFrameDarkMode to use new DWM API

Because 2 is one of many solutions to 1 but it's not the only solution. For instance, https://github.com/microsoft/terminal/issues/3425#issuecomment-558943616 is another solution.

@beviu commented on GitHub (Feb 20, 2020): This issue should probably be split into two issues: 1. Terminal has white borders in dark mode 2. Update ThemeUtils::SetWindowFrameDarkMode to use new DWM API Because _2_ is one of many solutions to _1_ but it's not the only solution. For instance, https://github.com/microsoft/terminal/issues/3425#issuecomment-558943616 is another solution.

claunia commented

@beviu commented on GitHub (Mar 2, 2020):

The more that I think about it, the more I wonder if it is possible that one of the devs who work at Microsoft can ask the people working on DWM (because it's also from Microsoft) why calling DwmExtendFrameIntoClientArea gives us a white border and how we can prevent it to fix this?

Since the beginning, I have been trying a lot of different weird workarounds to patch this because I have no idea how it works and I really want it fixed because it burns my eyes :) but nothing is really good. However maybe the people working on DWM could find a really simple fix in a few seconds because they know what's happening under the hood?

I used a program to see what API calls the ApplicationFrameHost.exe executable (which I think is the thing that manages UWP apps' windows) makes and it does call DwmExtendFrameIntoClientArea with parameters { 0, 0, 32, 0 } but it doesn't have that weird white border so I'm missing something.

@beviu commented on GitHub (Mar 2, 2020): The more that I think about it, the more I wonder if it is possible that one of the devs who work at Microsoft can ask the people working on DWM (because it's also from Microsoft) why calling `DwmExtendFrameIntoClientArea` gives us a white border and how we can prevent it to fix this? Since the beginning, I have been trying a lot of different weird workarounds to patch this because I have no idea how it works and I really want it fixed because it burns my eyes :) but nothing is really good. However maybe the people working on DWM could find a really simple fix in a few seconds because they know what's happening under the hood? I used a program to see what API calls the `ApplicationFrameHost.exe` executable (which I think is the thing that manages UWP apps' windows) makes and it _does_ call `DwmExtendFrameIntoClientArea` with parameters `{ 0, 0, 32, 0 }` but it doesn't have that weird white border so I'm missing something.

claunia commented

@DHowett-MSFT commented on GitHub (Mar 3, 2020):

@greg904 you're totally right. The main issue is, though, that we want to ship something that'll work properly (or quasi-properly) all the way back to 19H1 (build 18362), and any solution we get from the DWM team is going to have a very long lead time.

I've been around the block with them a few times about what we "should" be doing to be good platform citizens but also blend in with other applications on the system. 😄

I wouldn't be upset about a solution that calls DwmExtendFrameIntoClientArea(hwnd, {0}) and paints the top of the window -- Chromium (and therefore Edge) does it and Firefox does it. There's some downsides to doing it this way, but I would accept minor downsides for the visual improvement we'd get.

@DHowett-MSFT commented on GitHub (Mar 3, 2020): @greg904 you're totally right. The main issue is, though, that we want to ship something that'll work properly (or quasi-properly) all the way back to 19H1 (build 18362), and any solution we get from the DWM team is going to have a very long lead time. I've been around the block with them a few times about what we "should" be doing to be good platform citizens but also blend in with other applications on the system. :smile: I wouldn't be upset about a solution that calls `DwmExtendFrameIntoClientArea(hwnd, {0})` and paints the top of the window -- Chromium (and therefore Edge) does it and Firefox does it. There's some downsides to doing it this way, but I would accept minor downsides for the visual improvement we'd get.

claunia commented

@DHowett-MSFT commented on GitHub (Mar 3, 2020):

@greg904 (be careful investigating ApplicationFrameHost -- windows for modern applications get a little bit of special treatment, and they're actually slightly different in win32k, so we can't derive too much info from looking at how they work.)

@DHowett-MSFT commented on GitHub (Mar 3, 2020): @greg904 (be careful investigating ApplicationFrameHost -- windows for modern applications get a little bit of special treatment, and they're actually slightly different in win32k, so we can't derive _too_ much info from looking at how they work.)

claunia commented

@DHowett-MSFT commented on GitHub (Mar 5, 2020):

Alright, so here's the deal. I got agreement from the DWM team to ship an interim solution while they work to resolve the issue for Windows vNext. This interim solution comes in the form of a single DLL consumed through a NuGet package.

It's not amazing from the perspective of an open-source project, and I understand that. I'm happy to answer any questions.

@DHowett-MSFT commented on GitHub (Mar 5, 2020): Alright, so here's the deal. I got agreement from the DWM team to ship an interim solution while they work to resolve the issue for Windows vNext. This interim solution comes in the form of a single DLL consumed through a NuGet package. It's not amazing from the perspective of an open-source project, and I understand that. I'm happy to answer any questions.

claunia commented

@andrew-boyarshin commented on GitHub (Mar 6, 2020):

@DHowett-MSFT it's great to see collaboration with DWM team!
It is, however, disappointing to see the solution to the issue being private and non-opensource. I imagine this is due to it using private DWM API such as window attributes №19-20 and UXTHEME ShouldAppsUseDarkMode method resolved by ordinal. It appears DWM team doesn't want to widen the API surface, make these official. I hope Windows Composition team will consider sharing more (maybe non-documented, without examples, but at least headers and/or LIB files) to enable advanced 3rd party developers, those who understand the responsibility of using non-documented APIs, to solve the issues they face.

@andrew-boyarshin commented on GitHub (Mar 6, 2020): @DHowett-MSFT it's great to see collaboration with DWM team! It is, however, disappointing to see the solution to the issue being private and non-opensource. I imagine this is due to it using private DWM API such as window attributes №19-20 and UXTHEME `ShouldAppsUseDarkMode` method resolved by ordinal. It appears DWM team doesn't want to widen the API surface, make these official. I hope Windows Composition team will consider sharing more (maybe non-documented, without examples, but at least headers and/or LIB files) to enable advanced 3rd party developers, those who understand the responsibility of using non-documented APIs, to solve the issues they face.

claunia commented

@DHowett-MSFT commented on GitHub (Mar 6, 2020):

@andrew-boyarshin watch this space 😄

I think us using UXTHEME isn't entirely required; DWM likely does this for us, but we were following somebody else's example.

We'll get it all ironed out in the end.

@DHowett-MSFT commented on GitHub (Mar 6, 2020): @andrew-boyarshin _watch this space_ :smile: I think us using UXTHEME isn't entirely required; DWM likely does this for us, but we were following somebody else's example. We'll get it all ironed out in the end.

claunia commented

@michalhudecek commented on GitHub (Jun 18, 2020):

Why is the issue closed? The part about white border when the terminal window is focused is not fixed. I have accent color for title bars and window borders turned off. I cannot find an issue for that in GitHub

@michalhudecek commented on GitHub (Jun 18, 2020): Why is the issue closed? The part about white border when the terminal window is focused is not fixed. I have _accent color for title bars and window borders_ turned off. I cannot find an issue for that in GitHub ![image](https://user-images.githubusercontent.com/1215304/85066501-5fa0fa80-b1af-11ea-9366-1851b3fff218.png)

claunia commented

@DHowett commented on GitHub (Jun 18, 2020):

Light system theme, light terminal theme, light borders.

@DHowett commented on GitHub (Jun 18, 2020): Light system theme, light terminal theme, light borders.

claunia commented

@michalhudecek commented on GitHub (Jun 18, 2020):

But they are usually black. See Windows Settings screenshot

@michalhudecek commented on GitHub (Jun 18, 2020): But they are usually black. See Windows Settings screenshot ![image](https://user-images.githubusercontent.com/1215304/85067220-9e838000-b1b0-11ea-919f-f272f4864394.png)

claunia commented

@michalhudecek commented on GitHub (Jun 18, 2020):

Or Edge

@michalhudecek commented on GitHub (Jun 18, 2020): Or Edge ![image](https://user-images.githubusercontent.com/1215304/85067304-c1ae2f80-b1b0-11ea-97b4-76860404d584.png)

claunia commented