Physical Web Sites do not show up in Omnibox |
||||||
Issue descriptionApp 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>
,
Feb 24 2017
I don't see any rollout parameters in your design doc or launch bug. Can you please annotate both of those and this bug?
,
Feb 24 2017
Isn't PW launching to 100% in M57? Is it currently on to 100% on M57 Beta and M58 Canary?
,
Feb 24 2017
,
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.
,
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.
,
Feb 24 2017
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%.
,
Feb 24 2017
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.
,
Feb 24 2017
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]?
,
Feb 24 2017
#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!
,
Feb 24 2017
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?
,
Feb 25 2017
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.
,
Feb 27 2017
Hi all, Are you planning on doing 80% of beta? Please send something out to LR if so. Thanks!
,
Feb 27 2017
Hi Jason, We're pushing to 100% of beta: https://critique.corp.google.com/#review/148680911 I sent a note to chrome-launch-review@.
,
Feb 27 2017
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.
,
Feb 27 2017
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).
,
Mar 2 2017
https://bugs.chromium.org/p/chromium/issues/detail?id=695184 has been approved!
,
Mar 2 2017
Please mark this as fixed.
,
Mar 2 2017
,
Mar 2 2017
[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.
,
Mar 2 2017
Removing Merge-TBD, this was already merged for 695184: https://bugs.chromium.org/p/chromium/issues/detail?id=695184#c12
,
Mar 8 2017
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.
,
Mar 8 2017
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 |
||||||
Comment 1 by animohan@chromium.org
, Feb 24 2017Owner: mattreynolds@chromium.org