| 2016-06-23 07:24:31 |
Paweł Stołowski |
bug |
|
|
added bug |
| 2016-06-23 07:24:51 |
Paweł Stołowski |
description |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user.
This doesn't happen and works as expected if wizard is not involved in the boot sequence (e.g. if you force trusted prompt by removing /home/phablet/.config/.scopesLocationPrompt and ./.local/share/UbuntuLocationService/trust.db and rebooting), this suggests it's somehow related to the wizard.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that scopes registry signals a change early on the dash startup taking place immediately after pre-populating the scopes programmaticaly. This forces invalidateResults() and has the same effect as pull-to-refresh. I suspect this may be a race/timing issue caused by the fact that the wizard restarts all services like this:
QProcess::startDetached(QStringLiteral("sh -c \"initctl emit indicator-services-end; \
initctl stop scope-registry; \
initctl stop smart-scopes-proxy; \
initctl emit --no-wait indicator-services-start; \
initctl restart --no-wait maliit-server; \
initctl restart --no-wait indicator-messages; \
initctl restart --no-wait unity8-dash\"")); |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user.
This doesn't happen and works as expected if wizard is not involved in the boot sequence (e.g. if you force trusted prompt by removing /home/phablet/.config/.scopesLocationPrompt and ./.local/share/UbuntuLocationService/trust.db and rebooting), this suggests it's somehow related to the wizard.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that scopes registry signals a change early on the dash startup taking place immediately after pre-populating the scopes programmaticaly. This forces invalidateResults() and has the same effect as pull-to-refresh. I suspect this may be a race/timing issue caused by the fact that the wizard restarts all services like this:
QProcess::startDetached(QStringLiteral("sh -c \"initctl emit indicator-services-end; \
initctl stop scope-registry; \
initctl stop smart-scopes-proxy; \
initctl emit --no-wait indicator-services-start; \
initctl restart --no-wait maliit-server; \
initctl restart --no-wait indicator-messages; \
initctl restart --no-wait unity8-dash\"")); |
|
| 2016-06-23 07:31:34 |
Paweł Stołowski |
description |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user.
This doesn't happen and works as expected if wizard is not involved in the boot sequence (e.g. if you force trusted prompt by removing /home/phablet/.config/.scopesLocationPrompt and ./.local/share/UbuntuLocationService/trust.db and rebooting), this suggests it's somehow related to the wizard.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that scopes registry signals a change early on the dash startup taking place immediately after pre-populating the scopes programmaticaly. This forces invalidateResults() and has the same effect as pull-to-refresh. I suspect this may be a race/timing issue caused by the fact that the wizard restarts all services like this:
QProcess::startDetached(QStringLiteral("sh -c \"initctl emit indicator-services-end; \
initctl stop scope-registry; \
initctl stop smart-scopes-proxy; \
initctl emit --no-wait indicator-services-start; \
initctl restart --no-wait maliit-server; \
initctl restart --no-wait indicator-messages; \
initctl restart --no-wait unity8-dash\"")); |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user as intended. For some reason it happens only if wizard is involved in the boot sequence, and not if trusted prompt for location is just forced by removing .scopesLocationPrompt and trust store db.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that there is a forced refresh of scopes registry metadata early during the dash startup:
[2016-04-23:07:04:42.593] Refreshing scope metadata
[2016-04-23:07:04:42.982] "SettingsModel::update_child_scopes(): no scope with id 'com.canonical.scopes.weatherchannel'"
[2016-04-23:07:04:42.983] Dispatching search: "com.canonical.scopes.dashboard_dashboard" "" ""
[2016-04-23:07:04:42.987] Enabling location updates
This calls invalidateResults() and has the same effect as pull-to-refresh. |
|
| 2016-06-23 07:33:45 |
Paweł Stołowski |
unity-scopes-shell (Ubuntu): importance |
Undecided |
High |
|
| 2016-06-23 07:33:47 |
Paweł Stołowski |
unity-scopes-shell (Ubuntu): assignee |
|
Pawel Stolowski (stolowski) |
|
| 2016-06-23 07:52:39 |
Marcus Tomlinson |
unity-scopes-shell (Ubuntu): status |
New |
Confirmed |
|
| 2016-06-23 08:06:07 |
Paweł Stołowski |
unity-scopes-shell (Ubuntu): status |
Confirmed |
In Progress |
|
| 2016-06-23 08:07:39 |
Paweł Stołowski |
bug task added |
|
canonical-devices-system-image |
|
| 2016-06-23 08:10:14 |
Paweł Stołowski |
description |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user as intended. For some reason it happens only if wizard is involved in the boot sequence, and not if trusted prompt for location is just forced by removing .scopesLocationPrompt and trust store db.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that there is a forced refresh of scopes registry metadata early during the dash startup:
[2016-04-23:07:04:42.593] Refreshing scope metadata
[2016-04-23:07:04:42.982] "SettingsModel::update_child_scopes(): no scope with id 'com.canonical.scopes.weatherchannel'"
[2016-04-23:07:04:42.983] Dispatching search: "com.canonical.scopes.dashboard_dashboard" "" ""
[2016-04-23:07:04:42.987] Enabling location updates
This calls invalidateResults() and has the same effect as pull-to-refresh. |
The trusted prompt for location access for Scopes is shown immediately after the wizard and not after first search or pull-to-refresh initiated by the user as intended. For some reason it happens only if wizard is involved in the boot sequence, and not if trusted prompt for location is just forced by removing .scopesLocationPrompt and trust store db.
Looking at the unity8-dash.log file from the first boot after wiping the device, it seems that there is a forced refresh of scopes registry metadata early during the dash startup:
[2016-04-23:07:04:42.593] Refreshing scope metadata
[2016-04-23:07:04:42.982] "SettingsModel::update_child_scopes(): no scope with id 'com.canonical.scopes.weatherchannel'"
[2016-04-23:07:04:42.983] Dispatching search: "com.canonical.scopes.dashboard_dashboard" "" ""
[2016-04-23:07:04:42.987] Enabling location updates
This calls invalidateResults() and has the same effect as pull-to-refresh.
This is most likely caused by the network becoming available & remote scopes getting fetched for the first time, signaling new scopes get available to the shell.
To reproduce, reflash with --wipe or perform factory reset. |
|
| 2016-06-23 09:28:28 |
Paweł Stołowski |
branch linked |
|
lp:~stolowski/unity-scopes-shell/fix-early-location-prompt |
|
| 2016-06-24 14:14:48 |
Paweł Stołowski |
summary |
Location trusted prompt shown immediately after the wizard |
Location trusted prompt for Scopes shown immediately after the wizard |
|
| 2016-06-24 19:14:36 |
Jean-Baptiste Lallement |
canonical-devices-system-image: status |
New |
In Progress |
|
| 2016-06-24 19:14:40 |
Jean-Baptiste Lallement |
canonical-devices-system-image: milestone |
|
12 |
|
| 2016-06-24 19:14:45 |
Jean-Baptiste Lallement |
canonical-devices-system-image: importance |
Undecided |
High |
|
| 2016-06-24 20:30:38 |
Jean-Baptiste Lallement |
canonical-devices-system-image: status |
In Progress |
Fix Committed |
|
| 2016-06-25 00:02:04 |
Launchpad Janitor |
unity-scopes-shell (Ubuntu): status |
In Progress |
Fix Released |
|
| 2016-07-27 20:10:23 |
Pat McGowan |
canonical-devices-system-image: status |
Fix Committed |
Fix Released |
|
