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

Issue 695720 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Bug



Sign in to add a comment

Physical Web Sites do not show up in Omnibox

Project Member Reported by jasonkliu@chromium.org, Feb 24 2017

Issue description

App Version (from "Chrome Settings > About Chrome"): 58.0.3019.0 dev
iOS Version: 10.3 beta
Device: 6S

Steps to reproduce: 
Meet the conditions for Physical Web:
* Location "While Using"
* Bluetooth on
* Google as default search engine

Observed behavior: 
Physical Web sites show up in TodayView.  They do not show up in Omnibox.  The Settings > Privacy > Physical Web switch is off.

Expected behavior: 
Sites should show up in Omnibox.  Switch should be on. 

Frequency: 5/5
<number of times you were able to reproduce> 

 
Components: Internals>PhysicalWeb
Owner: mattreynolds@chromium.org
Might it have to do with our Finch config?
I don't see any rollout parameters in your design doc or launch bug.  Can you please annotate both of those and this bug?
Cc: mard...@chromium.org pinkerton@chromium.org
Isn't PW launching to 100% in M57? Is it currently on to 100% on M57 Beta and M58 Canary?
Cc: cma...@chromium.org linds...@chromium.org

Comment 5 by mmo...@chromium.org, Feb 24 2017

Since the reporter found the settings page, the physical web flag is enabled for them.

On startup, but only once on startup, we check if the user meets criteria for PW enrollment and we will set the settings toggle accordingly.  @jasonklie, did you change any settings around at some point?  If you had anything off in the past, we may have decided to un-enroll you already.

If you turn on the PW feature in privacy settings, you will see results in omnibox on Dev/Canary, Beta is still only enabled in a 10% omnibox experiment. 

Comment 6 by mmo...@chromium.org, Feb 24 2017

Few more notes

1. Matt already put up a patch to change the on-first-startup behaviour to on-every-startup to better match what we do in Android, but this isn't merged into m57 (should it?)

2. The privacy setting is actually unrelated to the TodayView feature, which has its own enrollment prompt.  Super annoying, indeed, but unlikely to affect normal users much (who usually aren't toggling PW on explicitly).  We can try to address in future version.
Thanks, Michal. If we're planning to launch PW in Omnibox for 100% in M57 Stable then we should turn it on M57 Beta for more than 10%. We told our TestFlight users to test it :). Maybe I incorrectly assumed it's on for all of M57 Beta. 

If there are no specific reasons to keep it at 10% then it should go to 100%.
My understanding was that this was on by default in Canary, Dev and Beta, and indeed if it's not it should be as the launch bug is to launch 100% in 57. 
I think I've found the repro case for the state I was in.

1. Download Chrome Dev
2. Open it and opt in to location permission
    > Here, I expect PW sites to show up.  They do in TodayView, but since this is Finch controlled, there is no setting and nothing appears in the Omnibox.
3. Press the home button and disable location permission
4. Force kill the app and reopen it
    > Now, the config is loaded and the setting appears.  Since the location is now switched to off, sites don't appear in the Omnibox (although they do in TodayView).


> Matt already put up a patch to change the on-first-startup behaviour to
> on-every-startup to better match what we do in Android, but this isn't merged
> into m57 (should it?
Changing this behavior wouldn't affect the above case (once you opt out, you are never likely to opt in). Is it possible that this can be modified so that once you meet all the conditions once, you're opted in [since location isn't a technical requirement]?
#9: There are a few policy conditions, and a few technical prerequisites.  I agree that we should set the setting to ON when the policy conditions are met, even if the feature remains OFF because of the technical limitations (like system location disabled temporarily).  I'll discuss with Matt about addressing!

#7: There is one flag (#enable-physical-web) which enables the PW feature: adds the PW privacy settings page, which controls access to BLE scanning and resolving through PWS.  This is already 100% on Android (as of m49?) but this flag has just been added to iOS in m56 and is going to 100% in m57.  We will push it to 100% in Beta channel ASAP.

However, there is another, separate experiment, specifically for the omnibox integration of PW results.  This is an omnibox-specific process, to validate that PW results are not detrimental to omnibox performance.  Once validated, we will graduate out to 100%.  Today we are still at 10% in Beta, though we are tracking progress to graduate out ASAP.  mpearson@ has been helping us here and Matt has been leading.  We are expected to follow the same process for Stable.

Hopefully I didn't miss anything!
I don't think you're going to get enough results for your performance tests at 10% of beta users for iOS. Can you do something like 80/10/10 in iOS beta channel?
I agree with the concern in #11.  

> On startup, but only once on startup, we check if the user meets criteria for PW
> enrollment and we will set the settings toggle accordingly. 
As a hypothetical scenario, let's say I am a M56 Chrome user with PW sites in my TodayView widget (Bluetooth on), Google as my default search engine, and Location off.  I upgrade to M57 and cold start the app again so the toggle is now present, but in the off position.

1) Let's say I want to enable PW sites in the Omnibox so I turn the location on.  Since the toggle switch is checked one time only, will I still see no sites even though I meet all the conditions?  The HC article [go/pzmvl] states that the troubleshooting steps are turning on Bluetooth and Location.  It also doesn't mention the search engine preference.

2) Skipping the steps in (1) above, I turn the toggle on.  Location is still off.  Will I see PW sites?  If so, the feature can be triggered without Location on and that permission is not necessary for sites to be seen.


> Matt already put up a patch to change the on-first-startup behaviour to 
> on-every-startup to better match what we do in Android, but this isn't merged 
> into m57 (should it?)
If (1) is true, this should be merged to ensure a better experience.  On the other hand, if a user enables location to see PW sites and then later disables location, the every-startup check would cause a loss in functionality.
Hi all,

Are you planning on doing 80% of beta?  Please send something out to LR if so.  Thanks!
Hi Jason,

We're pushing to 100% of beta: https://critique.corp.google.com/#review/148680911

I sent a note to chrome-launch-review@.


We're also enabling the feature params on the default omnibox experiment config so that more Beta users will see it:

https://critique.corp.google.com/#review/148690545

Once both these CLs land, the feature will be available for 90% of Bling TestFlight users. We'll keep running our experiment for a few weeks and then enable to 100%.

This is actually 70/10/10/10 because we have two experiment groups (one only enables zero query suggestions, one enables both zero query and after typing suggestions) and one control group.

In practice this means 80% of users will see both zero query and after typing suggestions, 10% will only see zero query, 10% will see neither.
I requested merge approval for the auto-enable fix:

https://bugs.chromium.org/p/chromium/issues/detail?id=695184

> 1) Let's say I want to enable PW sites in the Omnibox so I turn the location on.

With the steps in (1), enabling Location after starting Chrome will have no effect on the Physical Web preference. As you noted, it's only checked once at Chrome start.

> 2) Skipping the steps in (1) above, I turn the toggle on.

On iOS we don't require location for the feature itself, just the auto-enable logic. If you enable the Physical Web preference toggle without authorizing Chrome to use your location, you should still be able to use the feature. Deauthorizing location once the feature is enabled also has no effect.

> On the other hand, if a user enables location to see PW sites and then later disables location, the every-startup check would cause a loss in functionality.

The auto-enable check is only performed if the PW preference is in the default state. If the user manually toggles it, or if the auto-enable check enables/disables the feature, it will stay in the new state until the user changes it. In the given scenario there should be no loss in functionality (PW will stay enabled).
Please mark this as fixed.
Status: Fixed (was: Assigned)
Labels: Merge-TBD
[Auto-generated comment by a script] We noticed that this issue is targeted for M-57; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-57 label, otherwise remove Merge-TBD label. Thanks.
Labels: -Merge-TBD
Removing Merge-TBD, this was already merged for 695184:

https://bugs.chromium.org/p/chromium/issues/detail?id=695184#c12
Quick question: if someone is already opted in on the TodayView widget, are they automatically opted in to the Omnibox permission?  This is the majority of our current PW users. 
Not directly.

With Chrome m57, we are automatically enabling Physical Web for a set of users which match specific criteria.  It is exceptionally likely that most TodayView+Physical Web users will pass this criteria and be automatically enrolled.

Also, we expect this set, while a minority of overall Chrome users, to still be vastly larger than our minuscule number of existing TodayView+PW users.

Sign in to add a comment