User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160726073904 Steps to reproduce: Dear Mozilla Support, I'm a Windows 10 Pro User 64 Bit. I'm Using a "classic Theme", similar than Windows 2000 look, but with my own prefered color settings. ;-) Actual results: When i use this classic theme, then Firefox show the favorites with black color background, when i am scrol through the list. see attached picture with details. Expected results: Firefox should show the favorites with correct background color, as it appear when i expand the list. see attached picture with details.

Note: This issue appear with every Firefox-Theme! Only using Windows 10 default or Aero Lite Theme helps.

And one more note: I'm using this classic theme, which need to copy to: "C:\Windows\Resources\Ease of Access Themes" http://www.elves-castle.de/pc-tipps/windows-10-tipps-und-einstellungen.html#klassisches-design-theme And: This happens with the favorites which are saved and display in the bookmarks toolbar.

(In reply to Bernd from comment #1) > Note: This issue appear with every Firefox-Theme! > > Only using Windows 10 default or Aero Lite Theme helps. Does this reproduce with Windows 10's builtin high contrast themes? Does it happen in Firefox "safe mode"? Looking at your screenshots, I don't really understand the difference between the one where text is readable and where it isn't. What do you mean by "expand" and "scroll" ? Do the menus only go black while scrolling, and then go back to normal? Or you mean they go back when you move the mouse over them? Or something else?

Hello Gijs, First: Thank you for take care! :-) I have checked in Savemode, here appear the issue, too. And yes, the menu go to black (not readable) only, while moving with the mouse through the bookmarks list. If i leave the mouse the bookmark area, then it switch back to "realable" and i can go again and select my bookmark. Let me try to explain clear the steps to reproduce: 1) I have display the bookmarks toolbar, which contains subfolders. 2) Then, i make 1 mouse click on the folder within the bookmark toolbar: Result: The list is open and shown correct! 3) I start to move the mouse through the list Result: ~50% chance that the list is correct or 50% chance to switch into wrong display with black color 4) But if there is a folder, which contain so many bookmarks, that it touch the windows 10 taskbar, and i move the mouse below until i reach the Windows 10 taskbar - THEN: 100% always all bookmarks in this folder are shown with black background color. I assume, every win 10 user, who activate the win 10 "high contrast" classic theme, can reproduce this issue: Just display the bookmarks toolbar, and create here a subfolder with so many links, that the list touch the windows 10 taskbar. Then scroll in the list until the end.

So to be 100% sure, this also happens with the builtin high contrast themes, not just with the one you downloaded from the link in comment #2? If you try in safe mode (Help > Restart with add-ons disabled, which also turns off e.g. graphics hardware acceleration) does the problem go away? Can you post a copy of the raw data from about:support (Help > troubleshooting information) ?

Hello Gijs, I have tested today all high contrast themes: The most "high contrast" Windows 10 Themes have allover black background color -> here Firefox bookmarks are per default with back background color and green/yellow text color. -> That means with this theme the problem do not appear. BUT there exist one "high contrast" Theme in Win 10, which have per default WHITE background color: -> With this Theme, the issue appear in same way as in "my downloaded colorful" theme. No, if i go in firefox save mode, with all addons disabled, the problem go NOT away. Here the trouble shooting information - sorry it's in german language: Allgemeine Informationen ------------------------ Name: Firefox Version: 48.0 Build-ID: 20160726073904 Update-Kanal: release User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Betriebssystem: Windows_NT 10.0 x86 Fenster mit mehreren Prozessen: 0/1 (deaktiviert) Abgesicherter Modus: false Absturzberichte der letzten 3 Tage ---------------------------------- Alle Absturzberichte Erweiterungen ------------- Name: Adblock Plus Version: 2.7.3 Aktiviert: true ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Name: DownThemAll! Version: 2.0.19 Aktiviert: true ID: {DDC359D1-844A-42a7-9AA1-88A850A938A8} Name: Firefox Hello Beta Version: 1.4.4 Aktiviert: true ID: loop@mozilla.org Name: FireFTP Version: 2.0.28 Aktiviert: true ID: {a7c6cf7f-112c-4500-a7ea-39801a327e5f} Name: Multi-process staged rollout Version: 1.1 Aktiviert: true ID: e10srollout@mozilla.org Name: NoScript Version: 2.9.0.14 Aktiviert: true ID: {73a6fe31-595d-460b-a920-fcc0f8843232} Name: Pocket Version: 1.0.4 Aktiviert: true ID: firefox@getpocket.com Name: WEB.DE MailCheck Version: 3.3.3 Aktiviert: true ID: toolbar@web.de Name: Zoom Page Version: 15.1 Aktiviert: true ID: zoompage@DW-dev Grafik ------ Allgemeine Merkmale Compositing: Direct3D 11 Asynchrones Wischen und Zoomen: nichts WebGL-Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 750 Direct3D11 vs_5_0 ps_5_0) H264-Dekodierung durch Hardware: Yes; D3D11 blacklisted with DLL nvwgf2um.dll (10.18.13.5891); Using D3D9 API Direct2D: true DirectWrite: true (10.0.14393.0) GPU 1 Aktiv: Ja Beschreibung: NVIDIA GeForce GTX 750 Herstellerkennung: 0x10de Gerätekennung: 0x1381 Treiber-Version: 10.18.13.5891 Treiber-Datum: 11-5-2015 Treiber: nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um Subsys-ID: 00000000 RAM: 1024 Weitere Informationen ClearType-Parameter: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300 AzureCanvasAccelerated: 0 AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo ClearType-Parameter: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300 Wichtige modifizierte Einstellungen ----------------------------------- accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.hashstats_reported: 1 browser.cache.disk.smart_size.first_run: false browser.cache.disk.smart_size.use_old_max: false browser.cache.frecency_experiment: 3 browser.display.document_color_use: 1 browser.download.importedFromSqlite: true browser.places.smartBookmarksVersion: 8 browser.sessionstore.upgradeBackup.latestBuildID: 20160726073904 browser.startup.homepage_override.buildID: 20160726073904 browser.startup.homepage_override.mstone: 48.0 browser.urlbar.daysBeforeHidingSuggestionsPrompt: 3 browser.urlbar.lastSuggestionsPromptDate: 20160812 browser.urlbar.maxRichResults: 12 dom.apps.reset-permissions: true dom.mozApps.used: true dom.push.userAgentID: 8c74542243834f24be437c43bc2ac8d4 extensions.lastAppVersion: 48.0 font.internaluseonly.changed: false gfx.crash-guard.d3d11layers.appVersion: 48.0 gfx.crash-guard.d3d11layers.deviceID: 0x1381 gfx.crash-guard.d3d11layers.driverVersion: 10.18.13.5891 gfx.crash-guard.d3d11layers.feature-d2d: true gfx.crash-guard.d3d11layers.feature-d3d11: true gfx.crash-guard.status.: 2 gfx.crash-guard.status.d3d11layers: 2 gfx.crash-guard.status.d3d9video: 2 media.benchmark.vp9.fps: 99 media.benchmark.vp9.versioncheck: 1 media.gmp-eme-adobe.abi: x86-msvc-x64 media.gmp-eme-adobe.lastUpdate: 1468784789 media.gmp-eme-adobe.version: 17 media.gmp-gmpopenh264.abi: x86-msvc-x64 media.gmp-gmpopenh264.lastUpdate: 1468784790 media.gmp-gmpopenh264.version: 1.5.3 media.gmp-manager.buildID: 20160726073904 media.gmp-manager.lastCheck: 1471433004 media.gmp-widevinecdm.abi: x86-msvc-x64 media.gmp-widevinecdm.lastUpdate: 1468784798 media.gmp-widevinecdm.version: 1.4.8.866 media.gmp.storage.version.observed: 1 media.hardware-video-decoding.failed: false media.webrtc.debug.aec_log_dir: C:\Users\Bernd\AppData\Local\Temp media.webrtc.debug.log_file: C:\Users\Bernd\AppData\Local\Temp\WebRTC.log network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.database.lastMaintenance: 1471020837 places.history.expiration.transient_current_max_pages: 104858 plugin.disable_full_page_plugin_for_types: application/pdf plugin.importedState: true plugin.state.flash: 1 print.printer_Microsoft_Print_to_PDF.print_bgcolor: false print.printer_Microsoft_Print_to_PDF.print_bgimages: false print.printer_Microsoft_Print_to_PDF.print_duplex: -437918235 print.printer_Microsoft_Print_to_PDF.print_edge_bottom: 0 print.printer_Microsoft_Print_to_PDF.print_edge_left: 0 print.printer_Microsoft_Print_to_PDF.print_edge_right: 0 print.printer_Microsoft_Print_to_PDF.print_edge_top: 0 print.printer_Microsoft_Print_to_PDF.print_evenpages: true print.printer_Microsoft_Print_to_PDF.print_footercenter: print.printer_Microsoft_Print_to_PDF.print_footerleft: &PT print.printer_Microsoft_Print_to_PDF.print_footerright: &D print.printer_Microsoft_Print_to_PDF.print_headercenter: print.printer_Microsoft_Print_to_PDF.print_headerleft: &T print.printer_Microsoft_Print_to_PDF.print_headerright: &U print.printer_Microsoft_Print_to_PDF.print_in_color: true print.printer_Microsoft_Print_to_PDF.print_margin_bottom: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_left: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_right: 0.5 print.printer_Microsoft_Print_to_PDF.print_margin_top: 0.5 print.printer_Microsoft_Print_to_PDF.print_oddpages: true print.printer_Microsoft_Print_to_PDF.print_orientation: 0 print.printer_Microsoft_Print_to_PDF.print_page_delay: 50 print.printer_Microsoft_Print_to_PDF.print_paper_data: 9 print.printer_Microsoft_Print_to_PDF.print_paper_height: -1,00 print.printer_Microsoft_Print_to_PDF.print_paper_name: print.printer_Microsoft_Print_to_PDF.print_paper_size_unit: 1 print.printer_Microsoft_Print_to_PDF.print_paper_width: -1,00 print.printer_Microsoft_Print_to_PDF.print_resolution: 600 print.printer_Microsoft_Print_to_PDF.print_reversed: false print.printer_Microsoft_Print_to_PDF.print_scaling: 1,00 print.printer_Microsoft_Print_to_PDF.print_shrink_to_fit: true print.printer_Microsoft_Print_to_PDF.print_to_file: false print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_bottom: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_left: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_right: 0 print.printer_Microsoft_Print_to_PDF.print_unwriteable_margin_top: 0 services.sync.declinedEngines: tabs,history,forms,adblockplus services.sync.engine.history: false services.sync.engine.prefs.modified: false services.sync.engine.tabs: false services.sync.lastPing: 1471432955 services.sync.lastSync: Wed Aug 17 2016 13:31:18 GMT+0200 services.sync.numClients: 2 storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1468785889 ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found. Wichtige nicht veränderbare Einstellungen ----------------------------------------- JavaScript ---------- Inkrementelle GC: true Barrierefreiheit ---------------- Aktiviert: false Barrierefreiheit verhindern: 0 Bibliotheken-Versionen ---------------------- NSPR Minimal vorausgesetzte Version: 4.12 Verwendete Version: 4.12 NSS Minimal vorausgesetzte Version: 3.24 Basic ECC Verwendete Version: 3.24 Basic ECC NSSSMIME Minimal vorausgesetzte Version: 3.24 Basic ECC Verwendete Version: 3.24 Basic ECC NSSSSL Minimal vorausgesetzte Version: 3.24 Basic ECC Verwendete Version: 3.24 Basic ECC NSSUTIL Minimal vorausgesetzte Version: 3.24 Verwendete Version: 3.24 Experimentelle Funktionen -------------------------

Bernd, thanks very much for testing. I can reproduce the scroll issue on my win10 machine with the white high contrast theme. It seems this is an old regression. Then I tried to look when it regressed, which got a bit annoying because other things relating to this menu broke at various points, but AFAICT the trouble started here: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b44898282f21&tochange=32c3ccd8946c So basically this broke July 2013 (between the 13th and the 14th, to be precise). Without being able to bisect inbound it's quite hard to tell what's going on here. A couple of hypotheses: - Based on the similarity with bug 1141112, I somewhat suspect bug 888870, though it makes less sense that any of this is specific to scrolling. On the white high contrast theme, I can see a difference between the hover style (background dark purple) and the scrolling one (black), which doesn't seem like it'd be related to this stuff. Anyway, if possible it would be good if someone can verify that this also affects win8.1. - graphics changes, like e.g. bug 889515 - the xbl:children change (e.g. bug 890775) - some of the layout/svg changes... Ryan, do you still have infra to do local builds and narrow this down further, so we have a clue for where to start looking to fix this? It seems unlikely it'll actually be a Theme bug, but I dunno where in Core/Toolkit(XUL) this needs to go if we don't know why it's even doing this.

I can try, but I'm not sure what it'll take to build Gecko circa 2013 at this point either.

As an update, I've got things building successfully but haven't figured out how to reproduce the issue locally yet.

Bernd, can you try out the two builds below and confirm that "A" doesn't reproduce the problem while "B" does? If so, I can generate more builds in between to hunt this down. https://people.mozilla.org/~rvandermeulen/A-b44898282f21.zip https://people.mozilla.org/~rvandermeulen/B-32c3ccd8946c.zip If you find yourself getting complaints about missing DLLs on startup, try installing the Visual Studio 2012 redistributable. https://www.microsoft.com/en-us/download/details.aspx?id=30679

Helly Ryan, I have downloaded and unzip both packages, but i cannot start that firefox-versions, i receive the error message, that "msvcp110.dll" is missing, but could fix this issue by installing "MS Visual C++ 2012". I'm not able to check for 100% because both Version don't allow to import/add any bookmarks. But when i scroll through the menu it looks like that Version A is stable and don't have any display errors. On testing Version B i saw some display errors, but not the complete blackout. If you would send me a firefox version, which allow to add / import bookmarks, then i can finally test the issue! If you want to test yourself, just activate in Windows 10 the "white-background" high contrast THEME. kind regards, Bernd

Here a screenshot how Version A+B looks

And one last suggestion please, maybe you can choose as color for mark the current row, a "blue" which is a little bit more light, that it would allow to read the text in both cases fine: If text is in black color AND if text is in white color. See picture Version A - with black letters the blue is too dark. But other high contrast theme have white text color. kind regards and thank you for taking care! :-) Bernd

Thanks for looking at the builds, Bernd. To be clear, though, these are just regular builds of the code from mid-2013 without any extra customizations.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > Bernd, can you try out the two builds below and confirm that "A" doesn't > reproduce the problem while "B" does? If so, I can generate more builds in > between to hunt this down. > > https://people.mozilla.org/~rvandermeulen/A-b44898282f21.zip > https://people.mozilla.org/~rvandermeulen/B-32c3ccd8946c.zip > > If you find yourself getting complaints about missing DLLs on startup, try > installing the Visual Studio 2012 redistributable. > https://www.microsoft.com/en-us/download/details.aspx?id=30679 Yes, A is working and B is broken.

(In reply to :Gijs Kruitbosch from comment #15) > Yes, A is working and B is broken. Next round: https://people.mozilla.org/~rvandermeulen/A-0b5b6c4b0e3a.zip https://people.mozilla.org/~rvandermeulen/B-f2d3b5149d3a.zip https://people.mozilla.org/~rvandermeulen/C-3433a021847b.zip

(In reply to Ryan VanderMeulen [:RyanVM] from comment #16) > (In reply to :Gijs Kruitbosch from comment #15) > > Yes, A is working and B is broken. > > Next round: > https://people.mozilla.org/~rvandermeulen/A-0b5b6c4b0e3a.zip good > https://people.mozilla.org/~rvandermeulen/B-f2d3b5149d3a.zip bad > https://people.mozilla.org/~rvandermeulen/C-3433a021847b.zip bad

https://people.mozilla.org/~rvandermeulen/A-d578673157a5.zip https://people.mozilla.org/~rvandermeulen/B-c1443b4d7e51.zip https://people.mozilla.org/~rvandermeulen/C-388733080b91.zip https://people.mozilla.org/~rvandermeulen/D-09cb9725492e.zip

Hello Ryan, :-) For your last Versions (Comment 18): A - good B - good C - bad D - bad

That points to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c1443b4d7e51&tochange=388733080b91 which basically narrows it down to 888870. FWIW, I also checked what happened on a current nightly if I reverted the "supportedOS" stuff in the exe manifest to how it was before bug 888870 and rebuilt. That seemed to fix the issue. So I think this is a windows widget bug. Of course, reverting that change breaks other stuff (like styling of the titlebar) so we can't just do that, but it at least points us in a direction we can investigate. Jim, between this and bug 1141112, it feels like there's something wonky going on, maybe with the colours windows gives us based on the compat info in the executable or something? That or with mouse input, because I see other "hover artifacts" in the menus when I hover with the mouse (ie multiple items appear hovered/selected) that don't reproduce when I revert the manifest to pre-888870 state. Any chance you (or someone you nominate :-) ) can look into this?

(In reply to :Gijs Kruitbosch from comment #20) > That points to > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=c1443b4d7e51&tochange=388733080b91 which basically > narrows it down to 888870. > > FWIW, I also checked what happened on a current nightly if I reverted the > "supportedOS" stuff in the exe manifest to how it was before bug 888870 and > rebuilt. That seemed to fix the issue. So I think this is a windows widget > bug. Of course, reverting that change breaks other stuff (like styling of > the titlebar) so we can't just do that, but it at least points us in a > direction we can investigate. > > Jim, between this and bug 1141112, it feels like there's something wonky > going on, maybe with the colours windows gives us based on the compat info > in the executable or something? That or with mouse input, because I see > other "hover artifacts" in the menus when I hover with the mouse (ie > multiple items appear hovered/selected) that don't reproduce when I revert > the manifest to pre-888870 state. Any chance you (or someone you nominate > :-) ) can look into this? This feels more like a gfx bug where a compat feature we were relying on isn't applied anymore after marking the app as compat with a particular version of a os.

(In reply to Jim Mathies [:jimm] from comment #21) > (In reply to :Gijs Kruitbosch from comment #20) > > That points to > > https://hg.mozilla.org/integration/mozilla-inbound/ > > pushloghtml?fromchange=c1443b4d7e51&tochange=388733080b91 which basically > > narrows it down to 888870. > > > > FWIW, I also checked what happened on a current nightly if I reverted the > > "supportedOS" stuff in the exe manifest to how it was before bug 888870 and > > rebuilt. That seemed to fix the issue. So I think this is a windows widget > > bug. Of course, reverting that change breaks other stuff (like styling of > > the titlebar) so we can't just do that, but it at least points us in a > > direction we can investigate. > > > > Jim, between this and bug 1141112, it feels like there's something wonky > > going on, maybe with the colours windows gives us based on the compat info > > in the executable or something? That or with mouse input, because I see > > other "hover artifacts" in the menus when I hover with the mouse (ie > > multiple items appear hovered/selected) that don't reproduce when I revert > > the manifest to pre-888870 state. Any chance you (or someone you nominate > > :-) ) can look into this? > > This feels more like a gfx bug where a compat feature we were relying on > isn't applied anymore after marking the app as compat with a particular > version of a os. OK... Milan, is there someone on your team who'd be able to look into this and/or bug 1141112?

Simplified STR: 1) Windows 8.1, set the high contrast white theme 2) open firefox, open about:blank, or about:config 3) right-click move mouse over context menu options result: selective clearing of the highlight color on menu items

Bug 1022568 may be related, I'll finish up my testing on that bug today.

Hello Guys, any idea by when this issue may be fixed in Firefox? :-) Sure, this issue is not high priority .... ;-) Thank you, Bernd

Sotaro, can you take a quick look here? I think I can reproduce this (I can certainly reproduce the STR from bug 1141112).

I could reproduce the problem on Win10 by setting the high contrast white theme.

It seemed that the background of menu items which were changed from active to non-active were not re-drawn.

This bug seems to be a regression of Bug 794246. It added skipping drawing background of menu item if (aPart == MENU_POPUPITEM && aState == MBI_NORMAL). https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#1493 But its assumption seems to be broken since Win8.1 high contrast mode. If I disabled AssumeThemePartAndStateAreTransparent(), I did not see the problem.

With attachment 8909681 [details] [diff] [review], I confirmed the problem was addressed with high contrast mode on my win10 pc.

Sotaro, why does assuming the theme part and start are transparent break drawing? If that function returns true shouldn't we still draw correctly just slower?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #34) > If that function returns true shouldn't we still draw correctly just slower? If AssumeThemePartAndStateAreTransparent() return true, it makes always to skip DrawWidgetBackground. Then it should make faster. But it made backgrounds colors of themed widgets always to black with non-high contrast mode on Win 10 and with high contrast mode on Win 10. https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#1568 If AssumeThemePartAndStateAreTransparent() always return false, it still draw correctly and just slower. The problem of this bug was also addressed.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #34) > Sotaro, why does assuming the theme part and start are transparent break drawing? The problem happened only on themed widget. By Comment 20, the problem was triggered by Bug 888870. It just added Windows 8.1 support. When I enabled high contrast mode on Win 10, I saw the background color problem on themed widgets. There were 2 patterns. - After hover the menu item, its background color remained highlighted - After hover the menu item, its background color became black From it, I suspected that the problem was caused by background color drawing of themed widgets. nsNativeThemeWin::DrawWidgetBackground() does the background color drawing. I found that AssumeThemePartAndStateAreTransparent() controls skipping background color drawing of themed widgets. When I removed AssumeThemePartAndStateAreTransparent(), the problem was addressed.

Comment on attachment 8909681 [details] [diff] [review] patch - Disable AssumeThemePartAndStateAreTransparent() with high contrast mode since Win8.1 Review of attachment 8909681 [details] [diff] [review]: ----------------------------------------------------------------- Ok. Please put a description of your investigation (like you have in the bug comments) into the commit message.

Pushed by sikeda@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/aba0a23d9434 Disable AssumeThemePartAndStateAreTransparent() on high contrast mode since Win8.1 r=jrmuizel

Probably not worth the backport to ESR52, but seems worth a Beta request since we're so early in the cycle and the patch is pretty low-risk.

Comment on attachment 8909681 [details] [diff] [review] patch - Disable AssumeThemePartAndStateAreTransparent() with high contrast mode since Win8.1 Approval Request Comment [Feature/Bug causing the regression]: The bug was triggered by Bug 888870, but actual cause seems to be Bug 794246. [User impact if declined]: Background color of menu items are not rendered correctly on Windows high contrast mode. [Is this code covered by automated tests?]: None [Has the fix been verified in Nightly?]: Yes. Tested on nightly. [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No [Why is the change risky/not risky?]: The change just removed skipping rendering backgrounds of Themed widgets. [String changes made/needed]: None

Comment on attachment 8909681 [details] [diff] [review] patch - Disable AssumeThemePartAndStateAreTransparent() with high contrast mode since Win8.1 Trivial patch, early in the beta cycle, polishing, taking it Should be in 57b3

(In reply to Sotaro Ikeda [:sotaro] from comment #41) > [Is this code covered by automated tests?]: None > [Has the fix been verified in Nightly?]: Yes. Tested on nightly. > [Needs manual test from QE? If yes, steps to reproduce]: No. > [Is the change risky?]: No > [Why is the change risky/not risky?]: The change just removed skipping > rendering backgrounds of Themed widgets. Setting qe-verify- based on Sotaro Ikeda's assessment on manual testing needs.