PSA: Update your extensions ahead of upcoming bookmark sync changes

[Oliver Dunk]

Hi all,

We've just published a new blog post on upcoming changes that impact the `chrome.bookmarks` API.

Read it here: https://developer.chrome.com/blog/bookmarks-sync-changes

As always, please let us know if you have any questions or concerns.

Thanks,

Oliver on behalf of Chrome Extensions DevRel

[Mythical 5th]

Can you share a screenshot of the Bookmark Manager with both synced and non-synced folders? I have not been able to create both types in the same profile - when I turn sync on, everything gets synced. I was interested to know if there would be duplicated entries in the left panel and/or icons denoting the storage type.

Also, I can't reproduce the expected outcome when following the instructions in the blog post. Specifically, when choosing not to sync, bookmarks do not get saved to the syncing storage.

4c: Choose "No thanks" when asked if you want to turn on sync.

5: If you bookmark pages, they will be added to the syncing storage (enabling you to test the dual-storage case).

I was using Version 138.0.7204.23 (Official Build) beta (64-bit)

[Oliver Dunk]

Hi,

Can you share a screenshot of the Bookmark Manager with both synced and non-synced folders? I have not been able to create both types in the same profile - when I turn sync on, everything gets synced. I was interested to know if there would be duplicated entries in the left panel and/or icons denoting the storage type.

If a user has both types of folder, the bookmarks manager looks like this:

Also, I can't reproduce the expected outcome when following the instructions in the blog post. Specifically, when choosing not to sync, bookmarks do not get saved to the syncing storage.

Hmm, can you check:

• Is sync disabled? Sync is the old mechanism and this change only applies if it is not being used.
• Are you signed in to a Google Account? Of course, you will only see the account folders if you are.
• Do you have both flags enabled at chrome://flags?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Oliver Dunk]

A quick update on the rollout - we're going to enable this for a very small percentage of users early to get some initial data. We've updated the blog post to reflect this.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Lucas Everett]

Here are some screenshots to demonstrate the problem.

For the first screenshot, this is what I see after signing in but not syncing.

For the second screenshot, this is what I see if I sign in without syncing but don't have any bookmarks in the "only on this device folder", or if I sign in without syncing and later delete all bookmarks in that folder. This bookmarks bar folder doesn't have an ID of "1" since it's the "in your Google account one". However, upon syncing then the ID becomes "1" again as it's syncing to that local device folder.

Some stability is needed here. The ID of "1" should always exist and point to the local folder when not synced. It doesn't make sense that I can't as a user later decide to save to the local folder if I prefer after sign in but not sync. Isn't that the whole idea with this new behavior? The user should be able to decide what is local and what is in the account? It's now available only at first and then that folder is lost after the final bookmark is deleted. Even though it is stated that you shouldn't rely on the ID, that is still buggy behavior because even in the Chrome UI that local folder is no longer available after you delete the last bookmark in it.

[Lucas Everett]

I found some behavior that is a problem for my extension, Easy Speed Dial https://easyspeeddial.com/. The premise of my extension is no configuration is required. By default I use the folder ID "1" to display items in the bookmarks bar. That continues to work with the new sync changes as long as at least 1 bookmark exists in the local folder. If after signing in, but not syncing, the user deletes all bookmarks in their bookmarks bar folder, that folder is deleted by Chrome and is no longer available. That is unexpected behavior. The local folder should always exist, but with this change it only exists until all bookmarks are deleted, then it goes away forever.

On Tuesday, June 17, 2025 at 7:47:30 AM UTC-5 Oliver Dunk wrote:

[Lucas Everett]

I was able to resolve the issue for my extension by using the folderType key instead of relying on ID "1" existing. However, I still believe this behavior should be reconsidered due to historically always allowing to retrieve bookmarks from the bookmarks bar using ID "1". When getting help from web searches or LLMs that ID "1" is expected behavior across all browsers that support the bookmarks API.

[Claire Charron]

Hi Lucas,

Thanks for your questions about the new bookmarks model. I wanted to provide more context on the changes: we're enabling many of the account-powered features (including bookmarks) to sign-in rather than requiring sync. 

In summary this means:

• Signed in - save to account: Users can now save bookmarks to their Google account just by being signed into Chrome. This provides account features (access across devices, recovery) without the user needing to enable sync.

• Signed out - save to device: For users who prefer local storage, bookmark saving to their Google Account can be easily toggled off in settings, even when signed in (note this toggle is launching in M142). Alternatively, users can sign out of Chrome to use it locally 

Users in a fragmented state (i.e. with both local and account bookmarks) isn't a desired outcome, but an artifact of simplifying the user experience and avoiding unexpected data uploads. Our aim is to simplify the UI for the two main states: "signed out" or toggled-off (local-only) and "signed in with account data".

thanks,

Claire

[Jerry Krinock]

I have been publishing a bookmarks syncing app with Chrome extension since the beginning, 2010 or whatever.    After executing the bulk migration to the Google Account, I was a bit shocked to see all of my bookmarks disappear upon signing out of Google.  But after an hour or or so of testing per the James Lee blog post, spending some time in the garden tying up tomato plants, and a lot of head-scratching, I think I am finally beginning to understand this new bookmarks syncing logic.  But I don't quite understand that bookmarks syncing occurs even when I the sync switches are off in my profile.  Turn on Sync seems to have become useless.  Is it going to be removed in a future version?

[U. Mitaka]

When local-only top-level folders disappear (and reappear) for reasons already mentioned in this thread, the onRemoved (onCreated) events don't seem to fire (though they do for synced top-level folders), is this a bug? I've checked this in version 137.0.7151.119.

[Jerry Krinock]

Another question: Is this change being made in the open source part of Chromium which may eventually be adopted by Microsoft Edge, Opera, Vivaldi, Brave, Orion, etc.?  Currently I use the same code to decode and encode trees from all these browsers, because they have been the same, and I'm wondering if I should subclass or not.

[Shannon Whitley]

Thank you for the PSA.  I'm having a little trouble wrapping my head around the action I should take.   To me, it seems like I would need to know the current state (signed in or signed out) to display the appropriate bookmarks. 

Does that seem like the correct approach and is there an api call that will easily point me to the current state?

This is the pseudocode that I'm picturing:

if (signed_in) {

   get_account_bookmarks();

}

else {

   get_local_bookmarks();

}

Thanks!

[Jerry Krinock]

I agree with Shannon Whitley that such a signed_in API would be nice, just because this change seems to have the potential for edge cases and surprises for users which have yet to be discovered.  In addition, we may need notifications when that signed_in status changes.  Please read on…

Here is an example edge case:  User signs out of Google  for some reason, not realizing the consequences.  My bookmarks-syncing app sees the deletions and deletes these bookmarks in other web browsers.  Or it may not see this until later, because of the missing notification noted by U. Mitaka.  I'm not sure if that missing notification is a bug or a feature..  

Or the user manually discovers that many or all of their bookmarks have disappeared, as expected by the Chromiu team, but not by them.  User panics, uses my app and my extension to restore their "lost" bookmarks.  Later, user signs back into Google.  When the download occurs after some seconds, they have many duplicate bookmarks.

By the way, I think there should be an indication of "Downloading bookmarks, please wait" during those seconds after signing in.  It is rather upsetting to see no effect for 10 seconds, wonder what you did wrong, and then BOOM.

Also, I hope the roll-out of this is really slow, or even better, consider delaying it beyond tomorrow July 1 2025.  I got the email announcing this breaking change only 5 days ago.  I admit that I sat on it for two days, but you know developers have other things going on in business and in life.  Also, since the affected code is in my macOS native app, I need to push out an update to a native app, which is a more involved than updating an extension.

[Jerry Krinock]

The value of the new syncing attribute in user-editable items always matches that of their deepest ancestor (bookmarks_bar syncing=1, other syncing=1, bookmarks_bar syncing=0, other syncing=0).  So please tell me why the syncing attribute exists on user-editable items when it seems to be redundant.  Is there some case in which it is not redundant?  Understanding this may help prevent bugs.  Thank you.

[Tony Confrey]

Hi,

Another question, perhaps related to Shannons. My extension has bookmarks-bar-specific functionality. In my case it only makes sense to apply this to the currently visible bookmarks bar and its contents. Will there ever be a case where the contents of multiple bookmarks-bar folders are visible in the bookmarks-bar region of the browser screen? I assume not! Using the updated api, if there are multiple folders of type "bookmarks-bar", how do i tell which one is currently visible?

Thanks,

[Jerry Krinock]

Tony Confrey, the behavior I see is that the two bookmarks_bar in the API are concatenated for display in that top strip of the browser window.  All items from the synced bookmark_bar appear first, starting from the left, then if there is any space remaining, items from the local  bookmarks_bar.  There has never been a way to tell which items have made the cut.

[Claire Charron]

Hi folks,

A few other answers to questions in line - hope this helps clarify!

---

I have been publishing a bookmarks syncing app with Chrome extension since the beginning, 2010 or whatever.    After executing the bulk migration to the Google Account, I was a bit shocked to see all of my bookmarks disappear upon signing out of Google.  But after an hour or or so of testing per the James Lee blog post, spending some time in the garden tying up tomato plants, and a lot of head-scratching, I think I am finally beginning to understand this new bookmarks syncing logic.  But I don't quite understand that bookmarks syncing occurs even when I the sync switches are off in my profile.  Turn on Sync seems to have become useless.  Is it going to be removed in a future version?

Indeed syncing as a user-facing feature will be deprecated in a future version (described in a previous blog post). We’re aligning the sign-in model more closely to what users expect in an app or browser - sign in to get your stuff, sign out to keep it safe. We have implemented several UIs in Chrome to facilitate this transition. On sign in, users will see an in-product-help and the identity pill in the top right will also expand while data is downloaded (note: these are launching with the broader rollout in Q4). On sign out, users will see a confirmation dialog explaining that account data will be removed from the device.

When local-only top-level folders disappear (and reappear) for reasons already mentioned in this thread, the onRemoved (onCreated) events don't seem to fire (though they do for synced top-level folders), is this a bug? I've checked this in version 137.0.7151.119.

The changes require 138.0.7196.0 or later. Your understanding is correct, onRemoved and onCreated events will indeed be fired for the top-level folders. . 

Another question: Is this change being made in the open source part of Chromium which may eventually be adopted by Microsoft Edge, Opera, Vivaldi, Brave, Orion, etc.?  Currently I use the same code to decode and encode trees from all these browsers, because they have been the same, and I'm wondering if I should subclass or not.

The changes are in the open-source repo. Other Chromium-based browsers are aware but it’s not clear yet whether or not they’ll adopt this same model.

I agree with Shannon Whitley that such a signed_in API would be nice, just because this change seems to have the potential for edge cases and surprises for users which have yet to be discovered.  In addition, we may need notifications when that signed_in status changes.  Please read on…

For bookmarks management, it is advised to rely on the creation/deletion (onCreated/onRemoved) of the nodes rather than directly relying on the Sign in status. When the user signs in, you will get notified with the additional account bookmark nodes, and when the user signs out, you will be notified with the removal of those nodes. Handling those events should provide you with enough context to react to the user actions in Chrome, in a more accurate and direct way related to Bookmarks. Note that the internal bookmark management relies on the same pattern.

Here is an example edge case:  User signs out of Google  for some reason, not realizing the consequences.  My bookmarks-syncing app sees the deletions and deletes these bookmarks in other web browsers.  Or it may not see this until later, because of the missing notification noted by U. Mitaka.  I'm not sure if that missing notification is a bug or a feature..  

Or the user manually discovers that many or all of their bookmarks have disappeared, as expected by the Chromiu team, but not by them.  User panics, uses my app and my extension to restore their "lost" bookmarks.  Later, user signs back into Google.  When the download occurs after some seconds, they have many duplicate bookmarks.

Concerning the scenarios that you mentioned; note that signing out of Chrome is an explicit user action, where the user has a confirmation dialog that mentions removing their account data (including Bookmarks) from their current Chrome Profile. This cannot happen indirectly or without the user’s knowledge. Similarly, signing in to Chrome would bring back the user’s account data - which is also mentioned as a benefit during the signing in process.

De-duplication, if users do encounter this, would in most cases be resolved through name+URL-based deduping. Users can also resolve this via the batch upload in the Chrome UI, which employs a similar logic to the deduping that occurs via Sync today. 

By the way, I think there should be an indication of "Downloading bookmarks, please wait" during those seconds after signing in.  It is rather upsetting to see no effect for 10 seconds, wonder what you did wrong, and then BOOM.

This should take no more than a few seconds for ~5k+ bookmarks, so most users shouldn’t observe a noticeable delay. Please let us know if you do. In addition, as mentioned above, users will see an in-product-help notification the first time and the identity pill will expand while data is downloaded (note: these are launching with the broader rollout in Q4).

Also, I hope the roll-out of this is really slow, or even better, consider delaying it beyond tomorrow July 1 2025.  I got the email announcing this breaking change only 5 days ago.  I admit that I sat on it for two days, but you know developers have other things going on in business and in life.  Also, since the affected code is in my macOS native app, I need to push out an update to a native app, which is a more involved than updating an extension.

As initially announced, our roll-out will be careful and progressive . In the next 3 months, we will be launching these changes to only a subset of users (~1-2% of clients) and will monitor metrics. Assuming these look good, our roll-out will then complete in Q4.

The value of the new syncing attribute in user-editable items always matches that of their deepest ancestor (bookmarks_bar syncing=1, other syncing=1, bookmarks_bar syncing=0, other syncing=0).  So please tell me why the syncing attribute exists on user-editable items when it seems to be redundant.  Is there some case in which it is not redundant?  Understanding this may help prevent bugs.  Thank you.

This is correct, the `syncing` attribute between any child and parent nodes always matches throughout the tree structure (except for the root node as expected). Having the information present on each is done for consistency and simplicity of access.

[Shannon Whitley]

Thank you, @Claire Charron.  Your explanation below makes sense to me if the user is always running my extension.  -- Although I'd love for that to be the case, I imagine people may enable/disable/uninstall/reinstall my extension in various combinations.  I don't see how I can reliably count on being notified of the onCreated/onRemoved events.  Am I understanding the guidance correctly?  

For example, if my extension is not installed, and the user signs in (which triggers onCreated), I have missed the event.  The user then installs my extension, how would I know, at this point, if I should display account bookmarks or local bookmarks?

> For bookmarks management, it is advised to rely on the creation/deletion (onCreated/onRemoved) of the nodes rather than directly relying on the Sign in status. When the user signs in, you will get notified with the additional account bookmark nodes, and when the user signs out, you will be notified with the removal of those nodes. Handling those events should provide you with enough context to react to the user actions in Chrome, in a more accurate and direct way related to Bookmarks. Note that the internal bookmark management relies on the same pattern.

[U. Mitaka]

The changes require 138.0.7196.0 or later. Your understanding is correct, onRemoved and onCreated events will indeed be fired for the top-level folders.

After upgrading Chrome to version 138.0.7204.92, I confirmed that the onRemoved (onCreated) event also fires after a local top-level folder is removed (created). Thanks.

[Alesandro Ortiz]

>   people may enable/disable/uninstall/reinstall my extension

This would be an issue with the current model too. It's the extension's responsibility to check for changes in bookmarks if they have missed events due to being disabled or uninstalled. There's no reasonable expectation that a browser should handle cases where an extension isn't active or installed and misses events because of this. Extensions would need to call https://developer.chrome.com/docs/extensions/reference/api/bookmarks#method-getTree or equivalent to get the current bookmarks state. That should include whether the bookmark node is being synced or not.

[Shannon Whitley]

Thanks, @Alesandro Ortiz - Perhaps I can illustrate my question below.

In the future, when I call getTree(), my understanding is that there may be syncing and non-syncing nodes.  If I do not know the current state of the signed in account, how would I know which nodes to display?

    > Other bookmarks [syncing]

    > Other bookmarks [non-syncing]

This is the information I received in the notification email:
"Chrome will therefore separate syncing and non-syncing bookmarks into two separate subtrees in the bookmarks tree. In some cases where a user has not chosen to upload all of their bookmarks to their account, a user may have both syncing and non-syncing bookmark folders simultaneously."

Hint:  I saw another post that states the Bookmarks Bar concatenates the syncing and non-syncing bookmark lists. So, perhaps that is the guidance I'm looking for.

[Jerry Krinock]

Shannon, you display whatever you want to display, whatever you think your users will want :)  And, yes, the appearance of the Other Bookmarks in the main menu follows the same pattern as the Bookmarks Bar – all syncing items first, followed by all non-syncing items, with no indication of the division between them.

Since the dual-tree situation is an edge case, in my app I am displaying both the Bookmarks Bar and Other Bookmarks concatenated with no indication of the division.  And have fun if your app allows moving of bookmarks as mine does – the logic to merge the two trees on input and split them back on output is getting pretty complicated.

[Mythical 5th]

Shannon,

> how would I know, at this point, if I should display account bookmarks or local bookmarks?

The Omnibox shows results from both branches, as do the Bookmarks Bar and Other Bookmarks, as others have mentioned. This is in a signed-in state, the branches only get merged when the "Save in account" button is pressed.

[Shannon Whitley]

I appreciate the replies, @Jerry Krinock and @Mythical 5th.

To summarize the answer to my question:

If syncing and non-syncing nodes exist, the recommended approach is to display the syncing nodes, followed by the non-syncing nodes.  The display is left to the extension author.

Considerations:
- The extension author should evaluate issues such as bookmark duplication and surface the local/syncing status to reduce confusion for the user if needed.

- Review this note on the challenge of combining bookmark lists and moving nodes:  https://groups.google.com/a/chromium.org/g/chromium-extensions/c/zlZaK0Omvu0/m/VIWJp8v8BAAJ

[Mythical 5th]

> If syncing and non-syncing nodes exist, the recommended approach is to display the syncing nodes, followed by the non-syncing nodes.

I don't think we can assume this, because the Bookmark Manager displays the branches separately, as does the Details part of the Create Bookmark dialog (Ctrl+D), so users may be familiar with the tree structure and not want folders from separate branches combined in other UI contexts. Note that the Omnibox does not have anything to indicate whether folders there are synced or local, and neither does the Initial view of the Create Bookmark dialog -- I doubt this should be considered a recommendation either.

I'd rather see an icon by the folder name to indicate the folder source, but I don't know what an average user would want. This scenario occurs when a user has signed in to a profile which already has bookmarks, and they likely have not opened the Bookmark Manager where they would see the 2 branches and be asked to combine them. This user might understand the meaning of a sync icon or a computer icon next to a bookmark folder...but they might not.