Fix where Chrome Other bookmarks is not id 2

[mikedidomizio]

Some old references state that the "Other bookmarks" is always id 2 but it can be unique.

This pull request changes it so that it finds the "Other bookmarks", and returns the "id" that it finds.

I have no idea how to reproduce this issue accurately to help you verify.

The picture below shows the "Other bookmarks" with a different id. This is a Chrome profile that is a few years on Windows 10.

[1nfiniteloop]

Hi Mike,

Does "Other Bookmarks" always have the same id or does it change? What is the version of chrome where this happens?

These builtin nodes was earlier identified by it's title "Bookmarks bar" and "Other bookmarks" (Chrome) but caused issues when system languages was not in English, see bug #2 and 149411b. Then class "BuiltinBookmark" was added and these built-in folders were found by the hard-coded id instead.

[mikedidomizio]

Sorry should've included the version for Chrome which is 132.0.6834.197.

I just checked again and it is the same ID, so it's not changing. I did create a new Chrome profile and it was "2".

Language in Chrome settings:

1. English (United States)
2. English

[1nfiniteloop]

Interesting.. Let me know if you're able to reproduce and we can come up with a solution that works for both cases:

1. When system language is not English
2. When id is not 2

[mikedidomizio]

In Chrome 134, the Bookmarks API introduced a folderType. This folderType can be used to distinguish between these special type folders. The values are in English regardless of Chrome/System language.

I happened to stumble upon this Chrome Developer blog post and they mention:

As part of the identity model changes, Chrome will 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. Extensions which use the bookmarks API may need updating, in order to display the bookmarks tree in a way that is clear to users.

They showed an example of how the getTree API could look, with two "other bookmarks" with the difference being "syncing" as either "true" or "false".

Getting into that state without help is difficult, but it is possible.

Here are the steps:

• Sign in, have sync turned on
• Save a bookmark
• Sign out by "Turn off" Sync (it'll log you out)
• Bookmark something
• Sign in
• on "Turn on sync" modal, click "Settings"
• Open the extension, the "Other bookmarks" are split!

So I tried using folderType === 'other' to see how the extension behaved.

If I understand the code correctly, the reason we grab the "other bookmarks" node (previous ID=2) is to use that node's title to replace all the "other bookmarks" with ${BOOKMARKS_MENU}, so since both "other bookmarks" have the same title, it doesn't matter which one we grab, because it ends up working for both.

{
  "version": 3,
  "reference": "https://github.com/1nfiniteloop/json-bookmarks",
  "bookmarks": [
    {
      "title": "Ottawa: Local news and discussions / Nouvelles locales et discussions.",
      "url": "https://www.reddit.com/r/ottawa/",
      "path": "/${BOOKMARKS_MENU}"
    },
    {
      "title": "Boxing",
      "url": "https://www.reddit.com/r/Boxing/",
      "path": "/${BOOKMARKS_MENU}"
    },
    {
      "title": "Ottawa: Local news and discussions / Nouvelles locales et discussions.",
      "url": "https://www.reddit.com/r/ottawa/",
      "path": "/${BOOKMARKS_MENU}"
    }
  ]
}

There are some bugs that I've discovered.

ID is not fixed

The ID is not fixed as stated here.

folderType: this allows extensions to identify the "special" folders such as the bookmarks bar. Note that the name and id shouldn't be used for this purpose (name is locale-dependent, and id is not fixed)

In this PR I've also now changed the bookmarks bar node id to be grabbed by folderType as a separate commit. I'll leave it up to you if you want to include this change or not in this PR. I'm fine with just the "other bookmarks" change.

Import bug of multi-special folders

If you export, then import, it mashes them all under the same ${BOOKMARKS_MENU} and ${BOOKMARKS_BAR}.

I consider this a bug outside of scope of the PR, because it exists in the current production build regardless of this PR. I'm bringing awareness to it within this PR since I'm suggesting moving to folderType. I can create an issue with the bug I've described, and at least have it recorded.