New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 847171 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Folders and Apps in Folders are not visible in App launcher

Project Member Reported by mmanchala@chromium.org, May 28 2018

Issue description

Chrome Version:  69.0.3442.0/10728.0.0 dev-channel Candy,Daisy and Reks
OS: Chrome

What steps will reproduce the problem?
1)Sign in to user(Ex: A) -> logout -> sign in to another user(Ex:B) -> Go to Uber tray ->click on user I'd and select 'Sign in to another user...' option for Multiple sign-in
2)Now in Multiple sign-in User mode (B user will be active) click on Uber Tray and click on other (A user) -> click on App launcher and observe folders which are already created are not visible -> click on folder and observe Apps are also unable to view
3)Now click on Uber Tray and click on other user(B user) -> click on App launcher and observe folders ,Apps in folders are also unable to view
(Please refer Video and Screenshot)

Note: Issue is seen only in Multi user mode

Expected: Folders should be visible and also Apps in folders are also should be visible

Actual: Instead Folders are not visible, Empty fields are seen in place of folders and on clicking folder, apps also unable to view(Only Name of App is seen)

This is a Regression issue as same is working fine in M-67 Reks

@omrilo: Please confirm the Issue
 
Actual_FolderView.mp4
19.9 MB Download
Actual_FolderView.jpg
587 KB View Download
Labels: -M-68 M-69
Attaching expected videos for reference
Actual_AppsInFolderVew.jpg
2.5 MB View Download
Expected_FolderAndAppsView.jpg
2.1 MB View Download
Expected_FolderView.mp4
18.7 MB Download
Labels: ReleaseBlock-Beta
Adding Beta blocker as this is a recent regression, please remove if not required
Cc: weidongg@chromium.org omrilio@chromium.org
Owner: khmel@chromium.org
+khmel and weidongg who have worked on similar issues.

Comment 4 by khmel@chromium.org, Jun 6 2018

Status: Started (was: Assigned)

Comment 5 by khmel@chromium.org, Jun 6 2018

problem confirmed.

Comment 6 by khmel@chromium.org, Jun 8 2018

Issue 850778 has been merged into this issue.

Comment 7 by khmel@chromium.org, Jun 12 2018

crrev.com/c/1096545 is created.

Comment 8 by khmel@chromium.org, Jun 12 2018

Owner: hejq@chromium.org
Handover to Jiaquan as discussed in cl

Comment 9 by xiy...@chromium.org, Jun 15 2018

Owner: xiy...@chromium.org
I'll follow up on this after CL in #7 lands.
Project Member

Comment 10 by bugdroid1@chromium.org, Jun 15 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/115ece2fa4389731b58f27523666cd37804a0ec5

commit 115ece2fa4389731b58f27523666cd37804a0ec5
Author: khmel@google.com <khmel@google.com>
Date: Fri Jun 15 19:04:20 2018

app_launcher: Prevent setting empty icon for item.

This prevents race condition when icon is overrided from ash callback.
AppList <-> Ash communication is bi-directional and asynchronous.
Particular for this problem it introduces following. Item is created and
default Chrome app icon is assigned. That causes async call to Ash. Next
icon is updated (its loading is yet another async operation). Updated
icon is sent as the next call to Ash. At this moment we receive callback
from Ash that item is updated (resulting handling of item creation at
Ash). And that callback contains empty default icon from first call that
overwrites the actual icon. This problem is hidden in case of single
user profile because we don't send more icons to Ash. However in case of
multi-profile use case that problem comes to surface because existing
items are used to re-create Ash app list.

TEST=Manually

BUG:  847171 
Change-Id: I6aa3800d1b87c65fdad5e43c57246d42c1bead30
Reviewed-on: https://chromium-review.googlesource.com/1096545
Commit-Queue: Yury Khmel <khmel@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567751}
[modify] https://crrev.com/115ece2fa4389731b58f27523666cd37804a0ec5/chrome/browser/ui/app_list/chrome_app_list_model_updater.cc

Has this fix been tested in the latest version? Has it been resolved?
Issue not reproducible on latest M69 build (10895.5.0, 69.0.3497.14)
Status: Fixed (was: Started)
Labels: Merge-TBD
[Auto-generated comment by a script] We noticed that this issue is targeted for M-69; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-69 label, otherwise remove Merge-TBD label. Thanks.
Labels: -Merge-TBD
Verified that is on M69 branch already.

Sign in to add a comment