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

Issue 736443 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Change TetherService to listen on NetworkStateHandlerObserver::DevicePropertiesUpdated, not ::DeviceListChanged

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

Issue description

Listening on ::DeviceListChanged means TetherService calls its UpdateTetherTechnologyState() everytime almost anything happens, e.g. when a WiFi network changes. This leads to very annoying log spam.
 
Cc: steve...@chromium.org
You also need to update NetworkStateHandler to propagate the correct event. It currently calls the DeviceListChanged() handler. Theoretically, this should only be called if devices are added/removed from the list, and DevicePropertiesUpdated() should be called when a property of a device changes.

However, looking at the other instances of devices changing, it seems that several other places call DeviceListChanged() when only properties of a single device are being changed.

stevenjb@: Can you clarify when one should be called and when the other should be called? For example, [1] shows it being called in UpdateDeviceProperty(), which seems incorrect to me.

[1] https://cs.chromium.org/chromium/src/chromeos/network/network_state_handler.cc?l=1177
Both of those observers have evolved over time.

At this point DeviceListChanged is a superset; as the header comment says "The list of devices changed, or a property changed". It is intended to be used by observers that want to know when a device property may have changed. This shouldn't be all that frequent. Could you elaborate on what "almost anything" is in your observations?

DevicePropertiesUpdated should be used when updates for properties on a specific device are desired, but changes to the list of devices (e.g. adding or removing a device) are not interesting.



Owner: khorimoto@chromium.org
Status: Assigned (was: Available)
Thanks for the explanation, Steven!

So, looking into this more, I realize that the DeviceState class doesn't actually contain the technology state (enabled, unavailable, etc). That is stored within NetworkStateHandler. Looks like the correct thing to do is what we're already doing.

Thus, the only real issue here is that we log too much. I'll spin up a quick CL to fix this.
Status: Started (was: Assigned)
Project Member

Comment 5 by bugdroid1@chromium.org, Jun 28 2017

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

commit 9aa44ab0d44d18475363d33873f8160d9022cab1
Author: khorimoto <khorimoto@chromium.org>
Date: Wed Jun 28 23:33:39 2017

[CrOS Tether] Remove spammy log from Initializer.

Previously, we printed a warning log each time Init() was called when the feature had already been initialized. This resulted in spammy logs since this is expected to happen under some circumstances.

This CL also adds some extra tests in TetherService which ensure that Init() is called correctly.

BUG=672263, 736443 

Review-Url: https://codereview.chromium.org/2961733002
Cr-Commit-Position: refs/heads/master@{#483195}

[modify] https://crrev.com/9aa44ab0d44d18475363d33873f8160d9022cab1/chrome/browser/chromeos/tether/tether_service.cc
[modify] https://crrev.com/9aa44ab0d44d18475363d33873f8160d9022cab1/chrome/browser/chromeos/tether/tether_service.h
[modify] https://crrev.com/9aa44ab0d44d18475363d33873f8160d9022cab1/chrome/browser/chromeos/tether/tether_service_unittest.cc
[modify] https://crrev.com/9aa44ab0d44d18475363d33873f8160d9022cab1/chromeos/components/tether/initializer.cc
[modify] https://crrev.com/9aa44ab0d44d18475363d33873f8160d9022cab1/chromeos/components/tether/initializer.h

Status: Fixed (was: Started)

Comment 7 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment