Issue metadata
Sign in to add a comment
|
App EWMH icons are no longer set
Reported by
ivanmali...@gmail.com,
Oct 30 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.18 Safari/537.36 Steps to reproduce the problem: 1. Open an application that has a custom icon 2. View the custom ewmh icon that it set somehow 3. What is the expected behavior? A custom icon for the application should be displayed What went wrong? The default chrome/chromium icon is displayed. WebStore page: Did this work before? Yes I know that it worked in 58 but might have worked after this Chrome version: 63.0.3239.18 Channel: beta OS Version: 4.13.7-1-ARCH Flash Version:
,
Oct 30 2017
What do you mean by sample URL? This is an issue with apps, so there isn't an associated url.
,
Oct 30 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31 2017
Thanks for the update.Please provide the app details which is having custom icon / Sample test cases of the issue which would help us to triage the issue further. Thanks in Advance.
,
Oct 31 2017
hangouts, postman, google keep. Any app that has a custom icon really.
,
Oct 31 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 1 2017
for me, the issue is fixed in the latest google-chrome-unstable. OP, could you verify?
,
Nov 3 2017
@ ivanmalison: Request you to please provide an update as requested above. Thanks.!
,
Nov 3 2017
I'll take a look later today.
,
Nov 3 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 7 2017
@ ivanmalison Friendly ping Request you to please provide your observation as per c#7 Thanks!!
,
Nov 8 2017
Looking at this today.
,
Nov 8 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 9 2017
is unstable the same thing as beta? If so it does not seem to be fixed to me.
,
Nov 9 2017
~ ❯ google-chrome-unstable --version Google Chrome 64.0.3260.2 dev Things are still not working correctly for me.
,
Nov 9 2017
I can't reproduce, but perhaps you could bisect for us. We have a utility that makes this very easy, you don't need to do any builds or even have a chromium checkout. $ curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -d > bisect-builds.py $ python tools/bisect-builds.py -a linux64 -g 400000
,
Nov 10 2017
,
Nov 11 2017
Seems like the issue was introduced with this commit https://chromium.googlesource.com/chromium/src/+/1ddcada88969fcf84e51511060588094ddbd54c8 Here is the output from my bisect: ❯ python bisect-builds.py -a linux64 -g 400000 Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions) Downloading revision 462241...inux_x64/98320// Received 90820459 of 90820459 bytes, 100.00% Bisecting range [400004 (good), 515855 (bad)], roughly 15 steps left. Trying revision 462241... Revision 462241 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: r Bisecting range [400004 (good), 515855 (bad)], roughly 15 steps left. Trying revision 462241... Revision 462241 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 489447... Bisecting range [462241 (good), 515855 (bad)], roughly 14 steps left. Trying revision 489447... Revision 489447 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476483... Bisecting range [462241 (good), 489447 (bad)], roughly 13 steps left. Trying revision 476483... Revision 476483 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 482939... Bisecting range [476483 (good), 489447 (bad)], roughly 12 steps left. Trying revision 482939... Revision 482939 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 479612... Bisecting range [476483 (good), 482939 (bad)], roughly 11 steps left. Trying revision 479612... Revision 479612 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 478011... Received 95556539 of 95556539 bytes, 100.00% Bisecting range [476483 (good), 479612 (bad)], roughly 10 steps left. Trying revision 478011... Revision 478011 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 477197... Received 95399499 of 95399499 bytes, 100.00% Bisecting range [476483 (good), 478011 (bad)], roughly 9 steps left. Trying revision 477197... Revision 477197 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476883... Received 95382167 of 95382167 bytes, 100.00% Bisecting range [476483 (good), 477197 (bad)], roughly 8 steps left. Trying revision 476883... Revision 476883 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476642... Received 95371791 of 95371791 bytes, 100.00% Bisecting range [476483 (good), 476883 (bad)], roughly 7 steps left. Trying revision 476642... Revision 476642 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 476794... Received 95384187 of 95384187 bytes, 100.00% Bisecting range [476642 (good), 476883 (bad)], roughly 6 steps left. Trying revision 476794... Revision 476794 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476715... Bisecting range [476642 (good), 476794 (bad)], roughly 5 steps left. Trying revision 476715... Revision 476715 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 476755... Bisecting range [476715 (good), 476794 (bad)], roughly 5 steps left. Trying revision 476755... Revision 476755 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 476771... Bisecting range [476755 (good), 476794 (bad)], roughly 4 steps left. Trying revision 476771... Revision 476771 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476768... Bisecting range [476755 (good), 476771 (bad)], roughly 3 steps left. Trying revision 476768... Revision 476768 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 476761... Bisecting range [476755 (good), 476768 (bad)], roughly 2 steps left. Trying revision 476761... Revision 476761 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b You are probably looking for a change made after 476755 (known good), but no later than 476761 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/617fde26d470b3521f465971163b40566bd28520..1ddcada88969fcf84e51511060588094ddbd54c8 Can someone add khmel@chromium.org
,
Nov 11 2017
Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 11 2017
Thanks for the bisect. Over to khmel@
,
Nov 15 2017
@khmel any chance you can look at this soon?
,
Nov 15 2017
sure, looking.
,
Nov 16 2017
ivanmalison@ could you please provide more details about your test environment? I tested builds with/without my change and still could not find the diff. Probably I don't understand "View the custom ewmh icon that it set somehow" Are any repro steps for this? Thanks!
,
Nov 17 2017
@khmel I am referring to the _NET_WM_ICON property: https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317554480 Before your change, this property would get set to the extension's custom icon, but now it is set to the chrome/chromium icon no matter what. Obviously this only applies is if you are running X11, and somehow displaying the icons that are set in ewmh. I display the icons using https://github.com/travitch/taffybar It might be difficult to get that up and running though, so you can use the program xprop to take a look at the icon that is set for any given window. https://www.x.org/archive/X11R6.8.1/doc/xprop.1.html
,
Nov 17 2017
Thank you! Will try that.
,
Nov 21 2017
I use KDE, but I presume you should be able to use these repro steps in other desktop environments as well. 1. Open a site, such as https://www.google.com/ 2. Using 'add to desktop' menu, add a shortcut to the desktop. Make sure 'open in window' option is selected. This is important. 3. Click on the newly created shortcut. Now you can see that the window and the task bar are using two different icons. (See attached screenshot.)
,
Nov 25 2017
@ khmel@gmail.com Any progress on this? I'm fairly certain that it's related to the change that I mentioned above. https://chromium.googlesource.com/chromium/src/+/1ddcada88969fcf84e51511060588094ddbd54c8
,
Nov 27 2017
@ khmel@chromium.org are you able to reproduce using the xprop tool i mentioned?
,
Nov 27 2017
I tried xprop while ago but could not get success with builds prior my CL and after. Could you please let me know the OS version you use?
,
Nov 27 2017
You couldn't get success meaning that you couldn't get icons to show at all, or you could not get the correct icons to show? I run arch linux (see op), but this is not likely to be relevant. My xorg version is (X.Org X Server 1.19.5).
,
Nov 27 2017
#31. I applied icons using xprop set but icon did not change at all. xprop get confirmed that icon was changed in props.
,
Nov 27 2017
khmel@chromium.org this likely has to do with however the wm/de/bar/whatever you are using loads the icons. Also, I suspect that there are ways to set icons that don't use this EWMH protocol. The xprop tool should really only be used to confirm the existence of the regression i.e. use xprop on a revision before the change to verify that the EWMH icon is properly set to what it should be, and then use it again on a revision after the change to see that it is now just the default icon.
,
Nov 27 2017
Re #28: From the screenshot, you are using an older version of KDE. Try getting a go/rodete machine to get a more recent version of KDE.
,
Dec 1 2017
Bump. Any movement on here.
,
Dec 4 2017
I tested more platforms/desktop manager. I could not reproduce problem with taskbar. In all cases taskars show the right icon. I also failed to install taffybar due installation errors. I can confirm that xprop returns different icons for some apps. In case I open icon added by "Add to desktop" I see correct icons in all cases. So will take a look to xprop issue for that apps.
,
Dec 5 2017
,
Dec 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3297770730a8e432d951ad8faa675f21fe625a48 commit 3297770730a8e432d951ad8faa675f21fe625a48 Author: khmel <khmel@google.com> Date: Tue Dec 05 01:17:29 2017 Load app icon for Linux. This fixes the issue when Linux implementation of the assigning app icon for the window does not request image representation and as result icon is not loaded. Bug: 779463 Test: Manually Change-Id: I33ac3733ad1a428c6a448bc3845d2589ff640d09 Reviewed-on: https://chromium-review.googlesource.com/807398 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by: Elliot Glaysher <erg@chromium.org> Commit-Queue: Yury Khmel <khmel@google.com> Cr-Commit-Position: refs/heads/master@{#521569} [modify] https://crrev.com/3297770730a8e432d951ad8faa675f21fe625a48/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
,
Dec 5 2017
,
Dec 5 2017
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 5 2017
I think the CL landed after the M64 branch point, so requesting merge to M64 as well
,
Dec 5 2017
Is there an easy way for me to build this change to verify that it fixes the issue for me?
,
Dec 5 2017
#42 you may cherry-pick the change. I think you can do it for almost any branch. That file was not changing much. Would this work for you? git fetch https://chromium.googlesource.com/chromium/src refs/changes/98/807398/2 && git cherry-pick FETCH_HEAD
,
Dec 5 2017
Yeah but I'd need to build from source. I suppose I could look in to it.
,
Dec 5 2017
Rejecting merge to M63 per offline chat with khmel@ as this is P2. Thank you.
,
Dec 6 2017
Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3698c095c4bab8c7fc7e1d89b0b74d1ea54e2769 commit 3698c095c4bab8c7fc7e1d89b0b74d1ea54e2769 Author: khmel <khmel@google.com> Date: Fri Dec 08 23:34:14 2017 [Merge M64] Load app icon for Linux. This fixes the issue when Linux implementation of the assigning app icon for the window does not request image representation and as result icon is not loaded. TBR=khmel@google.com (cherry picked from commit 3297770730a8e432d951ad8faa675f21fe625a48) Bug: 779463 Test: Manually Change-Id: I33ac3733ad1a428c6a448bc3845d2589ff640d09 Reviewed-on: https://chromium-review.googlesource.com/807398 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by: Elliot Glaysher <erg@chromium.org> Commit-Queue: Yury Khmel <khmel@google.com> Cr-Original-Commit-Position: refs/heads/master@{#521569} Reviewed-on: https://chromium-review.googlesource.com/818303 Cr-Commit-Position: refs/branch-heads/3282@{#108} Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840} [modify] https://crrev.com/3698c095c4bab8c7fc7e1d89b0b74d1ea54e2769/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
,
Dec 11 2017
ivanmalison@ thank you for your help! I am going to close this now. Please feel free to reopen this or fill a new bug if you see any problem here after the fix.
,
Dec 12 2017
Unable to reproduce this issue on Ubuntu 14.04 using chrome latest stable #63.0.3239.84 and latest dev #64.0.3282.24 by following steps mentioned in the comment #26, observed the custom icon is displayed below as expected. Could some one confirm is this issue is reproducible only on specific window managers? Tested with cinnamon window manager on Ubuntu 14.04 unable to reproduce this issue on the reported version as well. Thanks!
,
Dec 13 2017
#50 Could you please verify which icon is set using xprop command?
,
Dec 13 2017
xprop shows the correct icon.
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒░▒▒▒░░▒▒▒▒▒
░▒▒░ ▒▒ ▒▒▒░
░▒▒░░ ▒░ ▒▒ ▒▒▒░
▒▒▒▒ ▒▒▒▒░ ▒▒▒
▒▒▒▒ ▒▒▒▒ ░▒▒▒
▒▒▒▒ ▒▒▒ ▒▒▒▒
░▒▒▒▒ ▒▒ ▒▒▒▒▒░
░▒▒▒▒ ▒▒ ▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
Icon (32 x 32):
░ ░
░░ ░░
░░░ ░░░
░░░░░░░ ░░░░░░░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒░░ ░░▒▒▒▒░░░░░░░▒▒▒▒▒▒
▒▒▒▒▒▒▒░ ░▒▒▒ ░▒▒▒▒▒
▒▒▒▒▒▒░ ░▒▒▒░ ░▒▒ ▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒ ▒▒▒▒░ ░▒▒ ▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒░░▒▒▒▒░ ░▒▒ ░▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒░ ░▒░ ░▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒ ▒▒░ ░▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒ ░▒▒▒░░▒▒▒ ░▒▒▒▒
▒▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒░ ▒▒▒▒
▒▒▒▒▒▒▒▒ ░▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒
▒▒▒▒▒▒▒ ░▒▒▒▒▒░░▒▒▒▒░ ▒▒▒▒
▒▒▒▒▒▒ ░▒▒▒▒▒▒ ░▒▒▒░ ░▒▒▒▒
▒▒▒▒▒░ ░░ ░░ ░▒▒▒▒
░▒▒▒▒▒ ░▒░ ░▒▒▒▒▒░
░▒▒▒▒▒▒░▒▒▒▒▒▒▒▒▒▒▒░░░▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
,
Dec 13 2017
Bad icon from the shelf might be taken from the system cache in case you ran this app before the fix. Could you please try to run Chrome on fresh data? --user-data-dir=/tmp/chrome_test_icon
,
Dec 13 2017
Tried using a fresh profile; issue is still reproducible. To be sure that there isn't anything cached, I tried engadget.com, which I have never opened in an app window.
,
Dec 13 2017
#54 - what is your display manager and task bar?
,
Dec 13 2017
KDE Plasma version 5.8.7. This is the KDE that's bundled with go/rodete.
,
Dec 13 2017
I don't know how useful it is, but this comment describes exactly what I see: https://www.reddit.com/r/kde/comments/5dz4lu/taskbar_icons_do_not_match_actual_application/dag9sig/
,
Dec 13 2017
I still see the original issue in Google Chrome 64.0.3282.14 @khmel does this version include your fix?
,
Dec 13 2017
#59 - You need 64.0.3282.18 +
,
Dec 13 2017
Awesome! Thanks @khmel. Things seem to be fixed!
,
Dec 13 2017
#57-58 - this might be KDE bug. With my fix we have identical logic what Windows does. We load app icon in 2 steps. At first step we use Chrome icon while we load custom app icon async. Once app is loaded we apply custom loaded icon. May be KDE ignores second icon set.
,
Dec 13 2017
Thank you everyone for help in this tricky issue! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rbasuvula@chromium.org
, Oct 30 2017Labels: Needs-Feedback Needs-Triage-M63