Saved wallpapers only load with a custom user-data-dir. |
||||
Issue descriptionSaved wallpapers fail to load on desktop Chrome OS build. With a linux-desktop build of Chrome OS: (1) Run chrome --login-manager (2) Set a wallpaper for a user account (right click desktop, etc.) (3) Close and restart chrome --login-manager. Expected: Wallpaper selected from previous session is loaded. Actual: Default gray wallpaper is shown, along with these error logs: [23635:23672:1011/131917:ERROR:wallpaper_manager_base.cc(588)] Failed to load custom wallpaper from its original fallback file path: /usr/local/google/home/msw/.config/chromium/custom_wallpapers/original/36e5ec38c03cdfb3019a8bc9b44c7bca8f63b61e/1476217116928 [23635:23672:1011/131917:ERROR:wallpaper_manager_base.cc(597)] Failed to load previously selected custom wallpaper. Fallback to default wallpaper. Expected wallpaper path: /usr/local/google/home/msw/.config/chromium/custom_wallpapers/original/36e5ec38c03cdfb3019a8bc9b44c7bca8f63b61e/1476217116928 This makes it difficult to assure I don't regress related functionality.
,
Oct 11 2016
Thanks! You're right, but why does specifying a user-data-dir matter? Shouldn't this work fine with the default user-data-dir? (~/.config/chromium/)
,
Oct 11 2016
Clicking around in the code base and I think the reason is that if the user-data-dir is not specified in the switch command, the custom wallpaper directory changes before and after the user logs in, so when the user sets a custom wallpaper after login, the custom wallpaper gets saved in a directory, whereas Chrome tries to retrieve the wallpaper in the login screen from a different directory. - WallpaperManagerBase::GetCustomWallpaperDir() uses chrome::DIR_USER_DATA to decide where to retrieve the wallpaper (https://cs.chromium.org/chromium/src/chrome/common/chrome_paths.cc?rcl=0&l=426) - If user-data-dir is empty, calls GetDefaultUserDataDirectory() to set it to be the default user data directory (https://cs.chromium.org/chromium/src/chrome/app/chrome_main_delegate.cc?rcl=0&l=407) - GetDefaultUserDataDirectory() calls GetXDGDirectory() calls PathService::Get(DIR_HOME, &path) to decide the default user data directory - DIR_HOME is overridden by UserSessionManager::OverrideHomedir() after the user logs in (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/session/user_session_manager.cc?rcl=1476199417&l=364)
,
Oct 11 2016
Thanks for your investigation! That seems like a legitimate, albeit minor, defect. I'll leave this issue available at Pri-3.
,
Oct 12 2016
If this is a regression in the last week or so, it's possible it's due to bug 654479 (I tightened security enforcement on access to filesystem: URLs, but we're seeing UMA reports indicating that we have introduced failures on chromeos, with no root cause yet). The wallpaper system appears to use webkitRequestFileSystem, so it's one of the causes we are suspecting. msw, if you are able to easily repro again, I'm wondering if about:histograms shows any samples of "FileSystem.OriginFailedCanCommitURL" after the failed load?
,
Oct 12 2016
Re#5: it's not a regression, it's been working this way forever...
,
Oct 13 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by x...@chromium.org
, Oct 11 2016