Public bug reported:

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\""));

** Affects: unity-scopes-shell (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  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\""));
+ 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\""));

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1595421

Title:
  Location trusted prompt shown immediately after the wizard

Status in unity-scopes-shell package in Ubuntu:
  New

Bug 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\""));

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1595421/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to