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

Issue 729179 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 747639
Owner:
Last visit > 30 days ago
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression

Blocking:
issue 726866



Sign in to add a comment

MessageCenter Notifications do not always display

Project Member Reported by hansberry@chromium.org, Jun 2 2017

Issue description

Chrome Version: 61.0.3118.0
OS: Platform 9576.0.0 veyron_minnie

For a few months our component has successfully been displaying notifications to the user via MessageCenter::AddNotification (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/net/tether_notification_presenter.cc?l=127). About 2 or 3 weeks ago, I noticed that notifications were no longer displaying. 

The extremely odd thing about this is that our notifications do display if the AddNotification callsite is changed. Take our TetherNotificationPresenter::NotifyMultiplePotentialHotspotsNearby() method (linked above) for example: this method is called indirectly through a callback from the system. However, if I place the method call in our setup code (called indirectly from UserSessionManager), the notification displays. It seems that notifications are only displaying for us when we try to display them during system setup / user login. 

Why does the callsite of MessageCenter::AddNotification matter (is it a process issue?)? Is MessageCenter not always available (even if MessageCenter::Get() is non-null)? Are certain flags being attached to Notifications that would prevent them from displaying?



 
Components: -UI>Shell>Notifications UI>Notifications
Cc: fukino@chromium.org
Owner: yoshiki@chromium.org
Status: Assigned (was: Untriaged)
yoshiki@, do you have any ideas on this issue?
My first assumption is threading. Calling message center methods on non-UI thread may break something. It looks NotifyMultiplePotentialHotspotsNearby() might be called on dbus-related thread and it may cause the issue?
I placed print statements checking the value of content::BrowserThread::CurrentlyOn(content::BrowserThread::UI) all throughout our code, including the callsite where NotifyMultiplePotentialHotspotsNearby() is called. In all places, content::BrowserThread::CurrentlyOn(content::BrowserThread::UI) returns true. Is it possible that the check is incorrect?
I tested for this issue on a sentry running 9623.0.0, 61.0.3123.0 -- the issue is not present (notifications appear just fine).

We also tested on a veyron_minnie running 9588.0.0, 61.0.3123.0 -- the issue is also not present.

Weirdly, it seems that the test image was causing this issue. It seems to be resolved now.
Status: WontFix (was: Assigned)
Mergedinto: 747639
Status: Duplicate (was: WontFix)

Sign in to add a comment