Was there any pre-testing going on on the Samus Y device?
Can you powerwash and repeat the test? 

I've looked through the UI-related code and can't figure out how this could be possible. Guess it's time to flash some Samuses again.

shrawan, can you please provide details on the test setup?

Interesting, I can reproduce this 100% in 49.0.2623.59 but only when signed in with my corp account. Other notifications (like the low-power charger) are working.

Do we suppress notifications somehow for enrolled users?

I ran the test again on two samus after power-washing the device and not able to reproduce the issue when on Y I had just one profile logged in. I could see the notification on  both samus as expected.

Then I added one more profile on Y after which started seeing no-notification issue consistently on Y-Samus. 

who does CrOS notification center stuff these days?

There haven't been changes recently.

jennyz@ can you take a look?

This is still happening. It's very weird, it occurs with my enrolled device's primary account, but not with non-corp accounts or dev-mode devices. I've tried across a range of versions from 52-55 and haven't found a pattern.

I take it that the settings dialog suggests that the right information is being sent to Chrome, and that the problem is around displaying the notification, right?

I haven't looked at this code before, but:

a) TrayPower::OnPowerStatusChanged unconditionally calls MaybeShowDualRoleNotification (if --ash-hide-notifications-for-factory isn't set).
b) MaybeShowDualRoleNotification creates a DualRoleNotification and calls its Update method if PowerStatus::Get()->HasDualRoleDevices() returns true.
c) PowerStatus::HasDualRoleDevices() returns true if the protobuf's supports_dual_role_devices field is set to true and available_external_power_source contains at least one source where active_by_default is false.
d) DualRoleNotification::Update creates or updates the notification unless:
   i) one of the sources is a DEDICATED_CHARGER (i.e. active_by_default == true)
   ii) nothing changed

The logic for the "nothing changed" case is fairly complicated:

  // Check if the notification should change.
  bool change = false;
  if (PowerStatus::Get()->IsLinePowerConnected() != line_power_connected_) {
    change = true;
    line_power_connected_ = PowerStatus::Get()->IsLinePowerConnected();
  } else if (new_source && dual_role_source_) {
    if (new_source->description_id != dual_role_source_->description_id)
      change = true;
  } else if (new_source || dual_role_source_) {
    change = true;
  } else {
    // Notification differs for 0, 1, and 2+ sinks.
    if ((num_sinks_found < num_dual_role_sinks_ && num_sinks_found < 2) ||
        (num_sinks_found > num_dual_role_sinks_ && num_dual_role_sinks_ < 2)) {
      change = true;
    } else if (num_sinks_found == 1) {
      // The description matters if there's only one dual-role device.
      change = new_sink->description_id != dual_role_sink_->description_id;
    }
  }

I'm a little bit nervous about how all of these conditions are chained, and some (particularly "new_source && dual_role_source_") have nested if statements. For example, it looks like if the source hasn't changed, we may skip the check for sink changes. Maybe this is intentional, though.

Do other notifications (e.g. low-power charger) still show up on the problematic devices?

#10: Yes, and yes.

The code has been touched a couple times since I last looked, but at the time I remember having *no* idea how it was possible.

@ketakid why was this archived?

Activating. Please assign to the right owner and the appropriate priority.

@michaelpg did you test this out a few weeks back?

#15: No, I was testing issue 693750. I'm mystified by both of these issues.

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.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot