How can an extension get the browser and profile name?

[Jerry Krinock]

Many years ago I asked in this group, and filed a bug somewhere, about the need for an extensions API to get the current browser and profile name.  This is necessary for extensions such as bookmark syncing which must distinguish among multiple browsers and profiles.

Our extension uses Native Messaging to communicate with our native syncing app.  Therefore, for example, if Firefox is running, and Chrome has two windows open in different profiles, there are three of our Native Messaging tool processes running on the system.  So that our native bookmarks syncing app can target its pushes and pulls to the desired browser+profile, each of these three processes opens an interprocess communication (IPC) port on the system, with the browser name and profile name incorporated into the IPC port name.

The tools get these names from their connected extension upon launch.  But since there seemed to be no API for our extension to get these names, we have designed our bookmarks syncing app to instruct the user to install our unlisted browser extension by clicking a button in our syncing app.  This button (1) commands the browser to browse to our extension in the store and (2) creates a file at a known path containing the desired browser name and profile name.  Upon loading, our extension reads this file, opens its IPC port with it, and also stores these names in localStorage.  For subsequent loads, the next day and forever, it reads this storage.

This kludge has worked without too much trouble for many years.  But we need to revisit it, because the localStorage which we have been using for the storage is deprecated in manifest v3.

I have searched the current extensions API Documentation and see lots of cool new API, but still have not found any way for an extension to get its profile name.  Is there an API I'm missing, or can someone think of a less kludgey kludge to get the profile name?

(The profile name is the difficult one.  Our Native Messaging tool could get its browser name be getting its parent process, although this is still somewhat fragile, particularly for browsers that publish separate "beta" and "production" versions.)

[wOxxOm]

You can still use localStorage in ManifestV3, it's not deprecated. The only restriction is that the service worker cannot access it directly, but it can create an offscreen document to read the storage and pass the result back via messaging.

FWIW, in Windows it's possible to read that info from the internal properties of the window identified by HWND passed in --parent-window command line switch to your host app:

System.AppUserModel.ID: ChromeCanary.WAZTY2CCFARNW2EJCY.UserData.Profile4
System.AppUserModel.RelaunchIconResource: C:\Users\******\AppData\Local\Google\Chrome SxS\User Data\Profile 4\Google Profile.ico,0
System.AppUserModel.RelaunchCommand: "C:\Users\******\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --profile-directory="Profile 4"
System.AppUserModel.RelaunchDisplayNameResource: Person 2 - Chrome

You can investigate the source code of System Informer to see how to obtain this info.

Some Chromium-based browsers like Opera or Vivaldi don't expose this info though and I don't know if they expose it somewhere else.

[Simeon Vincent]

Jerry, I still don't see a reason why you need the profile name. A profile name does not uniquely identify a profile; nothing prevents a user from assigning multiple profiles the same name. From the user's point of view, they can differentiate between these profiles using the profile's icon or simply the order that they appear in the profile switcher.

A more reliable way to identify a given extension instance is to generate a unique ID (for example, self.crypto.randomUUID()) at installation time and use that to identify a particular extension client that you're syncing with. The extension can persist this value in either chrome.storage or IndexedDB.

Simeon - @dotproto

incremental.software

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/4d9b7bcd-14a4-4f95-bc47-288e9c0daa2bn%40chromium.org.

[Jerry Krinock]

Thanks to wOxxOm and Simeon for the replies.

We use the profile name because, in the user interface of our app, the user needs to be able to edit (add and delete) which Chrome profile(s) they are syncing bookmarks with.  Therefore, whatever attribute we use must be recognizable by the user and reflect what they see in the user interface of Chrome.

I was quite surprised to learn that Chrome would allow the user to assign the same name to two different profiles!  The user can also assign the same avatar and same theme color, and after doing so the Profiles menu contains two items with identical appearance that open different profiles.  Not a good situation!  Fortunately, but not surprisingly, we have never had a support request from a user who so shot themself in the foot by assigning the same name to two profiles. Since such a user would first face confusion in Chrome, I'm not going to worry about it.

I also just tested our app and found that if the user changes their profile name in Chrome, the changed profile name is recognized by our app.  So apparently we are using maybe the immutable key name in the LocalState json file ("Default", "Profile 1", "Profile 2", etc.) under the hood.

Anyhow, back to the original topic – it appears that there is still no supported method to the get any kind of profile identifier from the WebExtensions API.  I've thought about those window properties (I suppose these would be the properties of an Offscreen Document in our extension), but have not found anything that would work on a Mac, and in Opera, Vivaldi, etc.  Therefore, we shall continue our past practice of setting the profile name as part of our installation process and storing it.