chrome renders yellow in 68+ (See workaround in c#59)
Reported by
kartride...@gmail.com,
May 26 2018
|
||||||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3438.3 Safari/537.36 Steps to reproduce the problem: 1. after updating to ver 68.0.3438.3 What is the expected behavior? What went wrong? chrome becomes yellow, both ui and web contents, except the omni bar. as the screenshot shows, the left two windows are opened as guest to make sure it's not caused by extensions, the right window shows the omni bar with right color. Did this work before? N/A Chrome version: 68.0.3438.3 Channel: dev OS Version: 10.0 Flash Version: Shockwave Flash 30.0 r0 what i tried: 1, disable all extensions 2, use default theme 3, restore all flags none works. weeks ago this issue came up in canary, then i switch to dev, and today i updated dev to 68.0.3438.3 which seems to catch up with canary...
,
May 27 2018
,
May 28 2018
I am observing the same issue on Linux - Fedora rawhide
,
May 29 2018
Same here. Chrome version: 68.0.3440.7 Channel: canary Windows 10 ver 1803 (OS Bukd 17134.48)
,
May 29 2018
Ok so I did some testing and it seems that it's only happening on my screen one. When I put browser on second display it's normal. Interestingly enough when more than 50% of the window is on the second screen, colors change to yellow shade.
,
May 30 2018
I am also getting this issue. I have a DELL XPS 15 laptop with 2 AOC monitors connected to it. When more than half of the Chrome canary window is on the DELL screen the colour is correct. If more than half is on the AOC monitor there is a yellow tint to the screen. Interestingly, Google's auto-suggest results in the navigation bar appear with a white background, not yellow. This has been happening for a couple of weeks now and may have been around the time of a large Windows 10 update I installed but I'm not certain about that.
,
May 30 2018
Unable to reproduce the issue on Win-10 using chrome reported version #68.0.3438.3 dev build and latest canary #69.0.3445.0. Attached a screen shot for reference. Following are the steps followed to reproduce the issue. ------------ 1. Launched chrome browser. 2. Observed that the chrome browser rendered white and did not render yellow. kartrider.wu@ - Could you please check the issue on latest canary #69.0.3445.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
May 30 2018
new profile without extensions nor apps, and all flags restored
,
May 30 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 31 2018
Unable to reproduce the issue on latest canary# 69.0.3446.0 using Windows-10 with steps mentioned below: 1) Launched chrome canary# 69.0.3445.0 and navigated to chrome://settings/help 2) Chrome got updated to latest canary# 69.0.3446.0 and clicked on Relaunch button, chrome got updated to 69.0.3446.0 and didn't observed chrome turning to yellow colour. Note: As unable to reproduce the issue from ET end, hence requesting someone from the UI>Browser team have a look at this issue. Thanks!
,
May 31 2018
Same issue here on Version 68.0.3440.7 (Official Build) dev (64-bit) Nvidia GeForce GTX 1060 Windows 10 1803 (happened on 1709, too) The problem disappears for me, if hardware acceleration is disabled in chrome settings.
,
May 31 2018
wow, disabling hardware acceleration "fixes" the problem. below is copied from chrome://gpu, may this could help. Graphics Feature Status Canvas: Hardware accelerated Flash: Hardware accelerated Flash Stage3D: Hardware accelerated Flash Stage3D Baseline profile: Hardware accelerated Compositing: Hardware accelerated Multiple Raster Threads: Enabled Native GpuMemoryBuffers: Software only. Hardware acceleration disabled undefined: Unavailable Rasterization: Hardware accelerated Skia Deferred Display List: Disabled Skia Renderer: Disabled Surface Synchronization: Enabled Video Decode: Hardware accelerated Viz Service Display Compositor: Disabled WebGL: Hardware accelerated WebGL2: Hardware accelerated Driver Bug Workarounds clear_uniforms_before_first_program_use decode_encode_srgb_for_generatemipmap disable_delayed_copy_nv12 disable_discard_framebuffer disable_framebuffer_cmaa exit_on_context_lost force_cube_complete scalarize_vec_and_mat_constructor_args texsubimage_faster_than_teximage Problems Detected Protected video decoding with swap chain is for Windows and Intel only Disabled Features: protected_video_decode Some drivers are unable to reset the D3D device in the GPU process sandbox Applied Workarounds: exit_on_context_lost TexSubImage is faster for full uploads on ANGLE Applied Workarounds: texsubimage_faster_than_teximage Clear uniforms before first program use on all platforms: 124764, 349137 Applied Workarounds: clear_uniforms_before_first_program_use Always rewrite vec/mat constructors to be consistent: 398694 Applied Workarounds: scalarize_vec_and_mat_constructor_args ANGLE crash on glReadPixels from incomplete cube map texture: 518889 Applied Workarounds: force_cube_complete Framebuffer discarding can hurt performance on non-tilers: 570897 Applied Workarounds: disable_discard_framebuffer Use GL_INTEL_framebuffer_CMAA on ChromeOS: 535198 Applied Workarounds: disable_framebuffer_cmaa Disable KHR_blend_equation_advanced until cc shaders are updated: 661715 Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent) Decode and Encode before generateMipmap for srgb format textures on Windows: 634519 Applied Workarounds: decode_encode_srgb_for_generatemipmap Delayed copy NV12 displays incorrect colors on NVIDIA drivers.: 728670 Applied Workarounds: disable_delayed_copy_nv12 Don't expose disjoint_timer_query extensions to WebGL: 808744 Native GpuMemoryBuffers have been disabled, either via about:flags or command line. Disabled Features: native_gpu_memory_buffers Viz service display compositor is not enabled by default. Disabled Features: viz_display_compositor Skia renderer is not used by default. Disabled Features: skia_renderer Skia deferred display list is not used by default. Disabled Features: skia_deferred_display_list Version Information Data exported 2018-05-31T14:40:59.681Z Chrome version Chrome/69.0.3446.0 Operating system Windows NT 10.0.17134 Software rendering list URL https://chromium.googlesource.com/chromium/src/+/9850f1f2cffb7b4e0b4ea26fd6fb94048a911cd5/gpu/config/software_rendering_list.json Driver bug list URL https://chromium.googlesource.com/chromium/src/+/9850f1f2cffb7b4e0b4ea26fd6fb94048a911cd5/gpu/config/gpu_driver_bug_list.json ANGLE commit id 95fb2a177412 2D graphics backend Skia/69 cf9086ce1ebd9efa27e96cfb09d9c72aac68aca1- Command Line "C:\Users\aa966\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --flag-switches-begin --flag-switches-end Driver Information Initialization time 261 In-process GPU false Passthrough Command Decoder false Direct Composition true Supports overlays false Sandboxed true GPU0 VENDOR = 0x10de, DEVICE= 0x1c82 *ACTIVE* GPU1 VENDOR = 0x8086, DEVICE= 0x1912 Optimus false AMD switchable false Desktop compositing Aero Glass Diagonal Monitor Size of \\.\DISPLAY2 21.4" Diagonal Monitor Size of \\.\DISPLAY1 23.5" Driver D3D12 feature level Not supported Driver Vulkan API version Not supported Driver vendor NVIDIA Driver version 23.21.13.9077 Driver date 1-23-2018 Pixel shader version 5.0 Vertex shader version 5.0 Max. MSAA samples 8 Machine model name Machine model version GL_VENDOR Google Inc. GL_RENDERER ANGLE (NVIDIA GeForce GTX 1050 Ti Direct3D11 vs_5_0 ps_5_0) GL_VERSION OpenGL ES 2.0 (ANGLE 2.1.0.95fb2a177412) GL_EXTENSIONS GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object OES_compressed_EAC_R11_signed_texture OES_compressed_EAC_R11_unsigned_texture OES_compressed_EAC_RG11_signed_texture OES_compressed_EAC_RG11_unsigned_texture OES_compressed_ETC2_RGB8_texture OES_compressed_ETC2_RGBA8_texture OES_compressed_ETC2_punchthroughA_RGBA8_texture OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture OES_compressed_ETC2_sRGB8_alpha8_texture OES_compressed_ETC2_sRGB8_texture Disabled Extensions GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent Disabled WebGL Extensions EXT_disjoint_timer_query EXT_disjoint_timer_query_webgl2 Window system binding vendor Google Inc. (adapter LUID: 000000000000b6b9) Window system binding version 1.4 (ANGLE 2.1.0.95fb2a177412) Window system binding extensions EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled Direct rendering Yes Reset notification strategy 0x8252 GPU process crash count 0 Compositor Information Tile Update Mode One-copy Partial Raster Enabled GpuMemoryBuffers Status ATC Software only ATCIA Software only DXT1 Software only DXT5 Software only ETC1 Software only R_8 Software only R_16 Software only RG_88 Software only BGR_565 Software only RGBA_4444 Software only RGBX_8888 GPU_READ, SCANOUT RGBA_8888 GPU_READ, SCANOUT BGRX_8888 Software only BGRX_1010102 Software only RGBX_1010102 Software only BGRA_8888 Software only RGBA_F16 Software only YVU_420 Software only YUV_420_BIPLANAR Software only UYVY_422 Software only Display(s) Information Info Display[2528732444] bounds=[-1920,0 1920x1080], workarea=[-1920,0 1857x1080], scale=1, external. Color space information {primaries_d50_referred: [[0.6416, 0.3340], [0.2812, 0.5996], [0.1436, 0.0713]], transfer:0.0039*x + 0.0000 if x < 0.0118 else (0.9999*x + 0.0001)**2.2004 + -0.0000, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[2779098405] bounds=[0,0 1920x1080], workarea=[0,0 1920x1080], scale=1, external. Color space information {primaries_d50_referred: [[0.6407, 0.3369], [0.3135, 0.6231], [0.1514, 0.0703]], transfer:0.0777*x + 0.0000 if x < 0.0450 else (0.9478*x + 0.0521)**2.4000 + -0.0000, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Video Acceleration Information Decode h264 baseline up to 4096x2304 pixels Decode h264 baseline up to 2304x4096 pixels Decode h264 main up to 4096x2304 pixels Decode h264 main up to 2304x4096 pixels Decode h264 high up to 4096x2304 pixels Decode h264 high up to 2304x4096 pixels Decode vp8 up to 7680x4320 pixels Decode vp8 up to 4320x7680 pixels Decode vp9 profile0 up to 7680x4320 pixels Decode vp9 profile0 up to 4320x7680 pixels Decode vp9 profile1 up to 7680x4320 pixels Decode vp9 profile1 up to 4320x7680 pixels Decode vp9 profile2 up to 7680x4320 pixels Decode vp9 profile2 up to 4320x7680 pixels Decode vp9 profile3 up to 7680x4320 pixels Decode vp9 profile3 up to 4320x7680 pixels Encode h264 baseline up to 3840x2176 pixels and/or 30.000 fps Encode h264 main up to 3840x2176 pixels and/or 30.000 fps Encode h264 high up to 3840x2176 pixels and/or 30.000 fps Diagnostics 0 b3DAccelerationEnabled true b3DAccelerationExists true bAGPEnabled true bAGPExistenceValid true bAGPExists true bCanRenderWindow true bDDAccelerationEnabled true bDriverBeta false bDriverDebug false bDriverSigned false bDriverSignedValid false bNoHardware false dwBpp 32 dwDDIVersion 12 dwHeight 1080 dwRefreshRate 60 dwWHQLLevel 0 dwWidth 1920 iAdapter 1 lDriverSize 948688 lMiniVddSize 0 szAGPStatusEnglish Enabled szAGPStatusLocalized 已启用 szChipType GeForce GTX 1050 Ti szD3DStatusEnglish Enabled szD3DStatusLocalized 已启用 szDACType Integrated RAMDAC szDDIVersionEnglish 12 szDDIVersionLocalized 12 szDDStatusEnglish Enabled szDDStatusLocalized 已启用 szDXVAHDEnglish Supported szDXVAModes szDescription NVIDIA GeForce GTX 1050 Ti szDeviceId 0x1C82 szDeviceIdentifier {D7B71E3E-5FC2-11CF-1B50-B2311BC2DA35} szDeviceName \\.\DISPLAY1 szDisplayMemoryEnglish 20117 MB szDisplayMemoryLocalized 20117 MB szDisplayModeEnglish 1920 x 1080 (32 bit) (60Hz) szDisplayModeLocalized 1920 x 1080 (32 bit) (60Hz) szDriverAssemblyVersion 23.21.13.9077 szDriverAttributes Final Retail szDriverDateEnglish 18/01/23 8:00:00 szDriverDateLocalized 1/23/2018 08:00:00 szDriverLanguageEnglish English szDriverLanguageLocalized 英语(美国) szDriverModelEnglish WDDM 2.3 szDriverModelLocalized WDDM 2.3 szDriverName C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll szDriverNodeStrongName oem73.inf:0f066de3900e3bc1:Section118:23.21.13.9077:pci\ven_10de&dev_1c82 szDriverSignDate Unknown szDriverVersion 23.21.0013.9077 szKeyDeviceID Enum\PCI\VEN_10DE&DEV_1C82&SUBSYS_11BF10DE&REV_A1 szKeyDeviceKey \Registry\Machine\System\CurrentControlSet\Control\Video\{6362EB21-4756-11E8-95A2-2215CEC28342}\0000 szManufacturer NVIDIA szMiniVdd 未知 szMiniVddDateEnglish Unknown szMiniVddDateLocalized 未知 szMonitorMaxRes Unknown szMonitorName SyncMaster 2413LW(Digital) szNotesEnglish No problems found. szNotesLocalized 没有发现问题。 szOverlayEnglish Supported szRankOfInstalledDriver 00D12001 szRegHelpText Unknown szRevision Unknown szRevisionId 0x00A1 szSubSysId 0x11BF10DE szTestResultD3D7English Not run szTestResultD3D7Localized 未运行 szTestResultD3D8English Not run szTestResultD3D8Localized 未运行 szTestResultD3D9English Not run szTestResultD3D9Localized 未运行 szTestResultDDEnglish Not run szTestResultDDLocalized 未运行 szVdd 未知 szVendorId 0x10DE 1 b3DAccelerationEnabled true b3DAccelerationExists true bAGPEnabled true bAGPExistenceValid true bAGPExists true bCanRenderWindow true bDDAccelerationEnabled true bDriverBeta false bDriverDebug false bDriverSigned false bDriverSignedValid false bNoHardware false dwBpp 32 dwDDIVersion 12 dwHeight 1080 dwRefreshRate 60 dwWHQLLevel 0 dwWidth 1920 iAdapter 0 lDriverSize 948688 lMiniVddSize 0 szAGPStatusEnglish Enabled szAGPStatusLocalized 已启用 szChipType GeForce GTX 1050 Ti szD3DStatusEnglish Enabled szD3DStatusLocalized 已启用 szDACType Integrated RAMDAC szDDIVersionEnglish 12 szDDIVersionLocalized 12 szDDStatusEnglish Enabled szDDStatusLocalized 已启用 szDXVAHDEnglish Supported szDXVAModes szDescription NVIDIA GeForce GTX 1050 Ti szDeviceId 0x1C82 szDeviceIdentifier {D7B71E3E-5FC2-11CF-1B50-B2311BC2DA35} szDeviceName \\.\DISPLAY2 szDisplayMemoryEnglish 20117 MB szDisplayMemoryLocalized 20117 MB szDisplayModeEnglish 1920 x 1080 (32 bit) (60Hz) szDisplayModeLocalized 1920 x 1080 (32 bit) (60Hz) szDriverAssemblyVersion 23.21.13.9077 szDriverAttributes Final Retail szDriverDateEnglish 18/01/23 8:00:00 szDriverDateLocalized 1/23/2018 08:00:00 szDriverLanguageEnglish English szDriverLanguageLocalized 英语(美国) szDriverModelEnglish WDDM 2.3 szDriverModelLocalized WDDM 2.3 szDriverName C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_ref_pubwu.inf_amd64_258f7a4f413a360c\nvldumdx.dll szDriverNodeStrongName oem73.inf:0f066de3900e3bc1:Section118:23.21.13.9077:pci\ven_10de&dev_1c82 szDriverSignDate Unknown szDriverVersion 23.21.0013.9077 szKeyDeviceID Enum\PCI\VEN_10DE&DEV_1C82&SUBSYS_11BF10DE&REV_A1 szKeyDeviceKey \Registry\Machine\System\CurrentControlSet\Control\Video\{6362EB21-4756-11E8-95A2-2215CEC28342}\0001 szManufacturer NVIDIA szMiniVdd 未知 szMiniVddDateEnglish Unknown szMiniVddDateLocalized 未知 szMonitorMaxRes Unknown szMonitorName DELL S2240M(Digital) szNotesEnglish No problems found. szNotesLocalized 没有发现问题。 szOverlayEnglish Supported szRankOfInstalledDriver 00D12001 szRegHelpText Unknown szRevision Unknown szRevisionId 0x00A1 szSubSysId 0x11BF10DE szTestResultD3D7English Not run szTestResultD3D7Localized 未运行 szTestResultD3D8English Not run szTestResultD3D8Localized 未运行 szTestResultD3D9English Not run szTestResultD3D9Localized 未运行 szTestResultDDEnglish Not run szTestResultDDLocalized 未运行 szVdd 未知 szVendorId 0x10DE 2 b3DAccelerationEnabled true b3DAccelerationExists true bAGPEnabled true bAGPExistenceValid false bAGPExists false bCanRenderWindow false bDDAccelerationEnabled true bDriverBeta false bDriverDebug false bDriverSigned false bDriverSignedValid false bNoHardware false dwBpp 0 dwDDIVersion 12 dwHeight 0 dwRefreshRate 0 dwWHQLLevel 0 dwWidth 0 iAdapter 0 lDriverSize 1905744 lMiniVddSize 0 szAGPStatusEnglish Enabled szAGPStatusLocalized 已启用 szChipType Intel(R) HD Graphics Family szD3DStatusEnglish Enabled szD3DStatusLocalized 已启用 szDACType Internal szDDIVersionEnglish 12 szDDIVersionLocalized 12 szDDStatusEnglish Enabled szDDStatusLocalized 已启用 szDXVAHDEnglish Unknown szDXVAModes Unknown szDescription Intel(R) HD Graphics 530 szDeviceId 0x1912 szDeviceIdentifier Unknown szDeviceName Unknown szDisplayMemoryEnglish 16227 MB szDisplayMemoryLocalized 16227 MB szDisplayModeEnglish Unknown szDisplayModeLocalized 未知 szDriverAssemblyVersion 23.20.16.4973 szDriverAttributes Final Retail szDriverDateEnglish 18/02/28 8:00:00 szDriverDateLocalized 2/28/2018 08:00:00 szDriverLanguageEnglish English szDriverLanguageLocalized 英语(美国) szDriverModelEnglish WDDM 2.1 szDriverModelLocalized WDDM 2.1 szDriverName C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_250db833a1cd577e\igdumdim64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_250db833a1cd577e\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_250db833a1cd577e\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\igdlh64.inf_amd64_250db833a1cd577e\igd12umd64.dll szDriverNodeStrongName oem66.inf:5f63e53470659c00:iSKLD_w10_DS:23.20.16.4973:pci\ven_8086&dev_1912 szDriverSignDate Unknown szDriverVersion 23.20.0016.4973 szKeyDeviceID Enum\PCI\VEN_8086&DEV_1912&SUBSYS_D0001458&REV_06 szKeyDeviceKey Unknown szManufacturer Intel Corporation szMiniVdd 未知 szMiniVddDateEnglish Unknown szMiniVddDateLocalized 未知 szMonitorMaxRes Unknown szMonitorName Unknown szNotesEnglish No problems found. szNotesLocalized 没有发现问题。 szOverlayEnglish Unknown szRankOfInstalledDriver 00D12001 szRegHelpText Unknown szRevision Unknown szRevisionId 0x0006 szSubSysId 0xD0001458 szTestResultD3D7English Not run szTestResultD3D7Localized 未运行 szTestResultD3D8English Not run szTestResultD3D8Localized 未运行 szTestResultD3D9English Not run szTestResultD3D9Localized 未运行 szTestResultDDEnglish Not run szTestResultDDLocalized 未运行 szVdd 未知 szVendorId 0x8086 Log Messages [3984:2200:0531/224055.736:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(49,8-58): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(57,9-43): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3984:13388:0531/224055.747:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(29,8-58): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(37,9-43): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3984:2200:0531/224055.758:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(46,8-58): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(54,9-43): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3984:13388:0531/224056.088:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(65,10-42): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(87,10-42): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3984:2200:0531/224056.983:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(46,8-58): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(54,9-43): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
,
Jun 1 2018
As we are unable to reproduce the issue from TE-end as per comment #7 and #11. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team. Thanks...!!
,
Jun 11 2018
This showed up as a trending issue in user feedback as well. It does look like it's only affecting users on version 68+. A few years ago we saw a similar issue and the root cause was due to a NVIDIA driver update - crbug.com/319115 - is this related?
,
Jun 11 2018
,
Jun 16 2018
Same issue on chrome version: 69.0.3452.0 The problem disappears for me too, if the flag: #enable-oop-rasterization is enabled.
,
Jun 18 2018
Cc'ing enne@ for inputs and further investigation as per C#18.
,
Jun 18 2018
Has the test team been able to try reproing using the same hardware and driver, in case it's a driver issue? Comment #18 is very curious. Oop rasterization shouldn't behave differently. If that's true, then maybe there's a GPU workaround in the command buffer that's causing this issue? Alternatively, there's some unknown unimplement color case (like color conversion?) somewhere that has been missed. I wonder a little if this is a color conversion issue. Does changing chrome://flags#force-color-profile to srgb make this issue go away?
,
Jun 18 2018
#13 is a NVidia + Intel (NVidia is active). I do wonder if it's a NVidia driver issue. Can anyone who's affected by this provide your about:gpu?
,
Jun 18 2018
Interesting: #enable-oop-rasterization has no effect here and does not fix the problem for me. But: #force-color-profile does: Default: Chrome is yellow All other options: OK Doesn't 'Default' effectively correspond to one of the options to choose from? I attached the content of chrome://gpu for both "#force-color-profile = Default" and "#force-color-profile = sRGB".
,
Jun 18 2018
The issue is related to your color profile then. Could you please attach your color profile (you can see which one is current by looking in Color Management as described here: https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit) The .icc or .icm file should be located in: C:\Windows\system32\spool\drivers\color Thank you!
,
Jun 18 2018
+brianosman -- did we change ICC libraries in 68?
,
Jun 18 2018
Looks like indeed SM245B.icm was the problem. I removed it in Color Management settings and Chrome now displays correctly again. Thanks!
,
Jun 18 2018
,
Jun 18 2018
Brian and I think we know what's going on here. This SM245B.icm color profile contains an XYZ matrix that transforms (1,1,1) to the D65 white point, (0.950, 1, 1.088). That's not what we'd expect in a valid ICC color profile... it should transform to the D50 white point (0.964, 1, 0.825). Our pre-skcms ICC parsing code rejected profiles like this that dodn't have a D50 white point, probably causing Chrome to fall back to sRGB. We overlooked this error case in skcms, so skcms parses the profile as if it's valid, and so when we target this relatively bluer D65 profile, everything looks yellower if interpreted as D50. You can kind of see the effect by looking at the concatenation of the sRGB XYZ matrix and this profile's inverse, showing what happens to sRGB colors as they're sent through: | 0.949066 0.173183 0.027867| | 0.002065 0.975680 0.000370| | 0.000229 -0.055756 0.772540| Red (sum of first row) is pumped up quite a bit, green (sum of second row) basically preserved, and blue (third) severely diminished. That is, it makes things yellow. We think the right thing to do is add this whitepoint-is-D50 check to skcms and reject profiles like this from now on. If you want a fun time, grab a Mac. You can add this profile to the available set of profiles by creating ~/Library/Colorsync/Profiles/ and copying the profile there. When you select it in the Displays pane of System Preferences, the whole screen will go yellow! (The Mac ICC parser is clearly not rejecting non-D50 color profiles.)
,
Jun 19 2018
I've got a CL ready that will reject this profile (and others like it): https://skia-review.googlesource.com/c/skcms/+/135708 However, I'm hesitating, mostly because so many other applications and libraries appear to accept these kinds of profiles and blindly apply them. The ICC spec makes it somewhat clear (as much as that document makes *anything* clear), that all profiles should be chromatically adapted to D50 white, and this profile definitely isn't. On the other hand, ColorSync, Photoshop, GNU IMP, etc... all allow that profile (and perform a pretty significant Blue <-> Yellow shift).
,
Jun 20 2018
Issue 854234 has been merged into this issue.
,
Jun 20 2018
#28 I understand your hesitance. Yes, all profiles should be chromatically adapted to D50. Sad fact is not all of them are, due to lack of clarity in the initial ICC specs, poor process when profiles are constructed, bad color EDID data in lower-end display devices, etc. I think the right answer might partly depend on your plans for skcms in future: professional use, consumer grade use, or do you want to serve both? We see from your comments, for example, that ColorSync allows the profile to be set on a target device (the display). The view is perhaps that users who do that do that know what they are doing (professional use). Consumer users on OSX won't do that, and their display color profiles are automatically set for them, and those profiles are known good for their display devices (assuming they are not using a third party display, which would potentially expose them to this bug). (One other thing you might test: attach any problem color profile to an image and render it in Safari. Does Safari (aka ColorSync) correct/ignore it? It might depend on whether the bogus color profile is on a source [image] or is a target profile [screen]). If you want to take skcms more in the direction of consumer grade use, there you can presume to fix, or reject bogus color profiles. Rejection is an interesting problem in itself: my color profile has bogus matrix parts say, but good A2B/B2A parts. Is it bogus? Code search for qcms_profile_is_bogus to see what's maybe ahead if one goes that way. My image has a profile with bogus TRC curves, is it bogus? Both ColorSync and QCMS would smooth over that problem, and accept the color profile :) For professional use cases, skcms should instead advise of errors, maybe not presume to fix them, and let the using software decide what to do. Perhaps that is the general solution: let using software (like chrome, or other clients you have) decide the ignore/fix/accept matter, perhaps by allowing them to configure some settings in skcms or similar, so that the using software has full control. Might take time to figure out though ... Meanwhile, we have chrome users on this bug that are exposed to bogus profiles, and are unsure of the problem cause, or how to fix. Chris has created a nice document to help them, and provided a Chrome setting to get them out of the trouble when they are exposed to problematic screen color profiles. That's seems a good/practical to me. However, the data I don't have is how well it works? Does it take up a lot of Chris's time (or the time of others involved in color)? Do the details get out to our forums and to our users, so they can fix? Do we get "a lot" of these types of bugs? I suppose if that is manageable so far, nothing to do? The process works and our users get fixed pronto. If it becomes unmanageable (aka a problem of scale) an automatic way to identify problem color profiles might become necessary.
,
Jun 20 2018
> Rejection is an interesting problem in itself: my color profile has bogus matrix parts say, but good A2B/B2A parts. Is it bogus? ... Yes, for our own sanity, we've decided that anything invalid poisons the entire profile.
,
Jun 21 2018
So here attached is a white square JPEG with this same profile. Because it's an image, the effect we've been seeing will go the other way, and it'll either look white or blue to you. Brian and I have looked at this image across a bunch of OSes, image viewers, editors, browsers, etc, and it seems like we'd be the odd ones out to reject this profile and draw it wihte as if sRGB. We're pretty strongly leaning towards not landing any change, and respecting these profiles even if they're a little crazy. Going to tentatively chalk this up as "Wont fix, working as intended", and then go put on my asbestos suit.
,
Jun 25 2018
The omnibox, main menu and dev tools are still white on Canary 69.0.3472.0 AND the test yellow. I installed a fresh instance of Beta 68.0.3440.33 and it is happening there too. I think the full program should render consistently.
,
Jun 26 2018
#34 I didn't quite follow what you mean by "AND the test yellow", but you might be affected by this issue. Let's assume so for now. The next steps were given in #23 above, which I'll repeat here for convenience #23 ------ Could you please attach your color profile (you can see which one is current by looking in Color Management as described here: https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit) The .icc or .icm file should be located in: C:\Windows\system32\spool\drivers\color ------ Hope that helps.
,
Jun 26 2018
No worries & thanks for the picture. Looking at it, I suspect your screen color profile is maybe causing the yellow. If you can follow the steps in #35, we can take a look at the color profile for you.
,
Jun 26 2018
I attach the icm file. I am starting to like the yellow color but it would be nice if the complete application would be of the same color.
,
Jun 27 2018
Agree: if we're gonna draw yellow, we should probably do that everywhere. First thing though, is to find out why your profile is making us draw yellow. A report for the color profile your provided in #38 is attached ...
,
Jun 27 2018
I think this is what's going on: 1) Chrome as of m68 respects profiles these kinds of profiles (those that introduce a hue to white). 2) As we said above, MacOS (and many other applications) also allow these kinds of profiles, and do the shift as well. In particular, I can assign this profile to an image in Photoshop (without complaint), and then have that image be drawn with an (inverse) hue shift in pretty much all software. 3) If I assign this profile to my monitor in Windows, the OS appears to reject, or (perhaps) correct the profile by using the wtpt tag to re-construct the chromatic adaptation matrix. None of the OS-managed drawing has the hue shift. 4) More interesting: If I open Photoshop after installing this profile for my monitor, I get a dialog that says: "The monitor profile ... appears to be defective. Please rerun your monitor calibration software." There are options to ignore the profile or use it anyway. So, on Mac, if want Chrome to look like everything else, we need to continue allowing and respecting these profiles. On Windows, we would have to ignore/correct them. I'm not even going to venture to guess what we should do on Linux, where color management is always inconsistent in every possible way. --- I realize this doesn't answer the question of users on Windows getting these inconsistent results, but if we do want to mimic the OS behavior, then we're going to need to add an option to skcms, and Chrome will need to make that policy decision.
,
Jun 27 2018
Problems with it are listed at the end. Your profile has an invalid white point tolerance, making the profile invalid [1]. I recommend you don't use it. > "I am starting to like the yellow color". It's kinda growing on me too :) But if you'd like to put things back to normal (white), then go to the "I Don’t Like It, How Do I Change It Back?" section in the document https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit and do the steps in the "For Windows Users" section. (I assume you are Windows user). Be sure to restart your chrome once you have done the steps, and the result should be ... no more yellow. [1] If we input white color to your color profile, it should produce white color output on your screen. The tolerance error tells us it does not produces white color. It in fact outputs a nearby color - yellow in your case :/
,
Jun 27 2018
(apols Brian #40, we crossed there a bit).
,
Jun 27 2018
No problem. I can almost imagine people intentionally making profiles like this to do "night light" features, although if you do want much warmer colors on your monitor, it's probably better to just adjust the color temperature settings of the monitor itself (though you may not be able to get as much control). And of course, that discards the benefits of color management (color accuracy is lost, so those nice yellow shoes you buy online may turn out to be gray or white when they arrive in the mail).
,
Jul 12
,
Jul 13
,
Jul 24
Issue 866756 has been merged into this issue.
,
Jul 24
After switching from Beta to Stable on June 8 because of the issue only existing on Google Chrome 68 and higher, today Google Chrome decided to update to Google Chrome 68 and I'm still experiecing the issue. However, this time I found a simple fix (a fix which didn't work in June): Disabling hardware acceleration removes the yellow tint for me.
,
Jul 24
Also, why exactly is this marked as "WontFix"? It clearly is an issue which exists, and as Google Chrome updated to Google Chrome 68 for a lot of users today, you will most likely see more posts about this soon.
,
Jul 24
Interesting, I just looked at Comment 35, forcing the sRGB color profile on chrome://flags works as well. I guess that's why the issue is marked as "WontFix", it's working as intended, but some users have broken Windows color profiles.
,
Jul 25
So, this was known since it was in DEV channel, and you still released this problem?... you might get a number of users moving to another browser, if they don't figure out how to get rid of this problem. I suggest you have something on Chrome settings (or somehow detect that Chrome became "yellow"), so users can get instructions on how to fix the problem (similar to what you have in the document above), or even better, make Chrome fix the problem for the user automatically.
,
Jul 25
Sigh. May I suggest urgently revisiting this? Had ~10 phone calls from angry users within a couple of hours following the v68 upgrade. - There's not a single user who'd wish to have things displayed like this. - Also, none of these users ever configured anything related to ICC profiles. They have no clue where to do it or what the ICM files are, even. So yeah, I can indeed see "a number of users moving to another browser" unless they can get professional support (which is the case for vast majority of home users).
,
Jul 25
Issue 867093 has been merged into this issue.
,
Jul 25
I'm traveling today, but given the steady influx of reports, I'm going to re-open this, and implement a white-point check in the display profile code (Windows only). I can get that up for review tomorrow, most likely.
,
Jul 25
,
Jul 25
,
Jul 25
,
Jul 25
,
Jul 25
,
Jul 26
While we wait for a fix to roll out, the easiest workaround is: 1) Open a tab in Chrome. 2) Go to 'chrome://flags' (enter that URL in the address bar) 3) In the search box at the top-center of the page, type 'color'. That will filter the list, and show two options. 4) The second option will be 'Force color profile'. Click where it says 'Default', and change it to 'sRGB'. This will require you to re-start Chrome, but at that point all of your colors should look like they did before.
,
Jul 26
,
Jul 26
Thanks, I fixed the error the way Thanks for helping Wish the product grow better
,
Jul 26
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/56adc578feec1e3fdadca2cf63c4759885e071b2 commit 56adc578feec1e3fdadca2cf63c4759885e071b2 Author: Brian Osman <brianosman@google.com> Date: Thu Jul 26 17:34:43 2018 Reject ICC profiles with a non-D50 white point This now matches behavior from before m68 (when we used a different ICC parser that rejected these profiles). In the longer term, I'd like to evaluate what Windows is doing with these profiles (ignoring them, or white point correcting them). Bug: chromium:847024 Change-Id: I662ea9217423d5c9a922ba1735d9de627133de12 Reviewed-on: https://chromium-review.googlesource.com/1150677 Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Osman <brianosman@google.com> Cr-Commit-Position: refs/heads/master@{#578354} [modify] https://crrev.com/56adc578feec1e3fdadca2cf63c4759885e071b2/ui/gfx/icc_profile.cc
,
Jul 26
,
Jul 26
This also need a merge to M69, pls request a merge to M69 as well. Thank you.
,
Jul 26
,
Jul 26
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 27
Workaround from #59: While we wait for a fix to roll out, the easiest workaround is: 1) Open a tab in Chrome. 2) Go to 'chrome://flags' (enter that URL in the address bar) 3) In the search box at the top-center of the page, type 'color'. That will filter the list, and show two options. 4) The second option will be 'Force color profile'. Click where it says 'Default', and change it to 'sRGB'. This will require you to re-start Chrome, but at that point all of your colors should look like they did before.
,
Jul 27
Tried testing the issue as per steps mentioned in comment# 23 by replacing the '.icm' file with the '.icc' file in C:\Windows\system32\spool\drivers\color path, in our local system we have three '.icc' files on which we are able to replace one '.icc' file with the '.icm' file that is provided in comment# 25, but unable to reproduce the issue on chrome reported version. Could anyone who are encountering the issue please verifying it on latest chrome canary and help us in verifying the fix. You can download latest chrome canary from URL: https://www.chromium.org/getting-involved/dev-channel. Thanks!
,
Jul 27
Your change meets the bar and is auto-approved for M69. Please go ahead and merge the CL to branch 3497 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 27
Please merge your change to M69 branch 3497 by 4:00 PM PT today, so we can pick it up for next week LAST M69 Dev release before Beta promotion. Thank you.
,
Jul 27
Hi All, the fix for this has landed in Canary. Can someone facing this issue currently please try the fix on today's Canary? You can download Canary on Windows and Mac here: https://www.google.com/chrome/canary/ Thanks!
,
Jul 27
I was able to verify this on Canary. I installed one of the profiles submitted by a user, and set it as default on my primary monitor. Chrome stable is (very) yellow. Canary is back to white.
,
Jul 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7b19081a1a9a1c1c2b8518482134df6fd9c2bd0d commit 7b19081a1a9a1c1c2b8518482134df6fd9c2bd0d Author: Brian Osman <brianosman@google.com> Date: Fri Jul 27 18:52:15 2018 Reject ICC profiles with a non-D50 white point This now matches behavior from before m68 (when we used a different ICC parser that rejected these profiles). In the longer term, I'd like to evaluate what Windows is doing with these profiles (ignoring them, or white point correcting them). Bug: chromium:847024 Change-Id: I662ea9217423d5c9a922ba1735d9de627133de12 Reviewed-on: https://chromium-review.googlesource.com/1150677 Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Osman <brianosman@google.com> Cr-Original-Commit-Position: refs/heads/master@{#578354}(cherry picked from commit 56adc578feec1e3fdadca2cf63c4759885e071b2) Reviewed-on: https://chromium-review.googlesource.com/1153527 Reviewed-by: Brian Salomon <bsalomon@google.com> Cr-Commit-Position: refs/branch-heads/3497@{#172} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/7b19081a1a9a1c1c2b8518482134df6fd9c2bd0d/ui/gfx/icc_profile.cc
,
Jul 27
Thanks for the verification. As discussed on chat, once it's verified that it was indeed broken (showing yellow) on 70.0.3503.0 and fixed (per #74) on 70.0.3504.0, please merge to M68. Conditionally approving: branch:3440
,
Jul 27
It is working now on Canary 70.0.3504.0 in Windows 10.
,
Jul 27
I was able to run 7503 and have it broken (yellow). 7504 running side-by-side is fixed. Going to merge to m68.
,
Jul 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3c0528653dd0ba4c04197e191b2bfe5bb0f1806f commit 3c0528653dd0ba4c04197e191b2bfe5bb0f1806f Author: Brian Osman <brianosman@google.com> Date: Fri Jul 27 19:34:23 2018 Reject ICC profiles with a non-D50 white point This now matches behavior from before m68 (when we used a different ICC parser that rejected these profiles). In the longer term, I'd like to evaluate what Windows is doing with these profiles (ignoring them, or white point correcting them). Bug: chromium:847024 Change-Id: I662ea9217423d5c9a922ba1735d9de627133de12 Reviewed-on: https://chromium-review.googlesource.com/1150677 Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Osman <brianosman@google.com> Cr-Original-Commit-Position: refs/heads/master@{#578354}(cherry picked from commit 56adc578feec1e3fdadca2cf63c4759885e071b2) Reviewed-on: https://chromium-review.googlesource.com/1153229 Reviewed-by: Brian Salomon <bsalomon@google.com> Cr-Commit-Position: refs/branch-heads/3440@{#763} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [modify] https://crrev.com/3c0528653dd0ba4c04197e191b2bfe5bb0f1806f/ui/gfx/icc_profile.cc
,
Jul 27
,
Jul 30
Issue 868655 has been merged into this issue.
,
Jul 30
,
Jul 30
Issue 868336 has been merged into this issue.
,
Jul 31
Issue 869389 has been merged into this issue.
,
Jul 31
The fix has been verified on the 68.0.3440.84 candidate build
,
Jul 31
hcm@, thank you so much for verifying the above fix.
,
Aug 1
also verified on 69.0.3497.23 |
||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||
Comment 1 by kartride...@gmail.com
, May 27 2018