New issue
Advanced search Search tips

Issue 828547 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

WifiPollingPolicy not obeyed for initial wifi scan

Project Member Reported by mattreynolds@chromium.org, Apr 3 2018

Issue description

Chrome should limit wifi scanning according to the WifiPollingPolicy, which typically restricts Chrome from scanning more than once every few minutes. However, the state used to enforce this policy is destroyed whenever the WifiDataProvider is stopped, which happens as soon as there are no active geolocation listeners. This allows callers to scan more frequently than allowed by ensuring the WifiDataProvider is recreated between each call.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 5 2018

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

commit abca656dd0f8e7aa02c21754ddb8581ab9e84b54
Author: Matt Reynolds <mattreynolds@chromium.org>
Date: Thu Apr 05 18:22:35 2018

Retain wifi policy state and last network position

While geolocation is active, the network geolocation provider
periodically scans using WLAN hardware to identify nearby wifi APs.
The set of APs is sent to a Google service which returns a position
estimate. Once there are no active geolocation listeners, the
wifi data provider and network location provider are shut down.

Some state retained by these providers must be preserved in order to
properly enforce the wifi polling policy. Previously, the policy state
was destroyed whenever there were no active geolocation listeners,
allowing a situation where wifi scans could be performed in rapid
succession as long as the providers were recreated each time. With this
CL, a newly-created WifiDataProvider obeys the policy for its initial
scan.

When a newly-created WifiDataProvider is denied an initial scan, it may
cause a newly-created NetworkLocationProvider to fail to acquire fresh
wifi data in a timely manner. This may cause a related issue where a
Geolocation call is unable to acquire a fresh estimate due to policy,
and has no cached value to return, leading to long delays or timeouts on
Geolocation API calls. To provide a good experience in this situation,
NetworkLocationProvider's cache of the most recent network position
estimate is moved to LocationArbitrator where it is retained when the
provider is recreated. The cached value may be returned when it is
sufficiently recent and no new data is available.

BUG=828547

Change-Id: I7b25929404b4becd28c13a20f0a7f5fc74894334
Reviewed-on: https://chromium-review.googlesource.com/993752
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548489}
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/BUILD.gn
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/location_arbitrator.cc
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/location_arbitrator.h
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/network_location_provider.cc
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/network_location_provider.h
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/network_location_provider_unittest.cc
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_data_provider_common.cc
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_data_provider_common.h
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_data_provider_common_unittest.cc
[add] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_polling_policy.cc
[modify] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_polling_policy.h
[add] https://crrev.com/abca656dd0f8e7aa02c21754ddb8581ab9e84b54/device/geolocation/wifi_polling_policy_unittest.cc

Status: Fixed (was: Started)
Labels: -OS-Linux -OS-Windows -OS-Mac
Status: Started (was: Fixed)
This is still broken on ChromeOS, which uses an alternate implementation of the wifi_data_provider (wifi_data_provider_chromeos).
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 7 2018

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

commit 99fa72cc64fc2bc7efea6f0887fa297c31e7efc6
Author: Matt Reynolds <mattreynolds@chromium.org>
Date: Thu Jun 07 15:23:52 2018

Retain wifi polling policy state on ChromeOS

In a previous CL, WifiDataProvider implementations for
other platforms were modified to retain the wifi polling
policy state across restarts of the WifiDataProvider. This
CL updates the Chrome OS implementation to also retain this
information across provider restarts.

Relevant commit:
https://chromium.googlesource.com/chromium/src/+/abca656dd0f8e7aa02c21754ddb8581ab9e84b54

When the wifi polling policy state is lost, Chrome fails to
correctly apply the initial polling delay the next time the
WifiDataProvider is restarted. This can result in excessive use
of WLAN hardware and the network geolocation service when
the geolocation API is called many times in rapid succession.

BUG=828547

Change-Id: Iecad5b7f12f2d8fc72196db9e2108a7d2286d7bd
Reviewed-on: https://chromium-review.googlesource.com/1089190
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565272}
[modify] https://crrev.com/99fa72cc64fc2bc7efea6f0887fa297c31e7efc6/device/geolocation/wifi_data_provider_chromeos.cc
[modify] https://crrev.com/99fa72cc64fc2bc7efea6f0887fa297c31e7efc6/device/geolocation/wifi_data_provider_chromeos.h

Sign in to add a comment