M69 Theme Sync Off fails
Reported by
larrylac...@yahoo.com,
Jul 14
|
|||||
Issue descriptionChrome Version : 69.0.3489.0 OS Version: 10.0 Other browsers tested: none - NA M69 UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3489.0 Safari/537.36 M67 UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 What steps will reproduce the problem? 1. Open profile in M69 (canary), with settings sync all 2. Turn off sync themes, sync settings, leave the settings tab open 3. Open new tab, go Web Store, load theme, e.g. Slinky Glamour https://chrome.google.com/webstore/detail/slinky-glamour/phcgjdgneipghoeikoeenifpknfkjpil?hl=en-US 4. Theme displays OK in M69 5. Open profile in M67 67.0.3396.0 (stable), has sync all, no theme 6. M67 session updates to theme - see screenshot What is the expected result? M67 does not receive synced theme What happens instead of that? M67 theme updates Additional information: Once you close the M69 settings tab, with the updated sync theme setting, or restart the M69 profile, the theme propagation stops. In my test environment, my main profile was always open, in both M67 and M69 and I opened/closed the test profile in M67, M69 as needed. M67 and M69 were running on the same device: Win10 laptop. As this is relatively short lived failure case, latency only immediately after changing the sync settings for test, general impact is probably low. There may be other sync settings latency issues. This is the only one I encountered.
,
Jul 17
,
Jul 20
Able to reproduce the issue on chrome reported version# 69.0.3489.0 and on latest chrome# 69.0.3496.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged.
,
Jul 23
It's currently working as intended. Sync settings change apply only after close the settings page. This is a feature request. Assigning to our PM.
,
Jul 24
Does the 'apply on close' caveat apply to all settings changes or only Sync settings? Do you have to close all settings tabs to apply the sync changes or only close the sync tab? Note: Help pages do not mention 'close to apply', e.g. https://support.google.com/chrome/answer/165139?hl=en https://support.google.com/chrome/answer/114836?hl=en&co=GENIE.Platform=Desktop Thanks: Functions as designed is close enough, but curious about the details.
,
Aug 31
One option discussed was to introduce an apply button on that page to clarify semantics
,
Aug 31
FYI: There is also a race window. If you logoff to block sync, so you can adjust the sync settings, you can't until you signin. There's a race window between when the user signs in and the 10 seconds later when he is able to reach the settings> sync page to disable the sync functions. Better: allow adjust sync settings while not signed in.. But the use case is so seldom, it's probably not worthwhile fixing.. Thanks, close enuf..
,
Sep 3
Changing the current behavior so that the settings take effect immediately has clear downsides (bandwidth costs for users playing around with the toggles, syncing up data before a user has turned on passphrase encryption, etc.) that outweigh the potential benefits. I'm going to bring up the idea to introduce an the pattern of an "apply" button up with the UX team, and in case we're going to pursue this idea, we're going to open up a new bug to track progress.
,
Sep 4
Thx. TBD if applicable on mobile. On the desktop, it's pretty common for me/users to close the tab after changing the settings - only power users/devs are likely to see the problem. On Android, I suspect after sync settings changes, users use a 'back' action to leave the page, which does the apply. Flipping to another app without leaving the settings page should be rare.
,
Sep 20
I filed crbug/887251 to track the feature request.
,
Sep 23
Looks like bug 887034 is a dup (wont fix). I couldn't find bug 887251 (yet). Thx |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Jul 17