1Password extension on second instance of Chrome working weird

Options
jinux_go
jinux_go
Community Member
edited April 2023 in 1Password in the Browser

I have two Chrome instances running. One is launched normally (from Spotlight) and another one is launched with the different User Data Directory parameter (--user-data-dir). (This is for separating two Chrome profiles completely. Having two profiles in one instance has some limitation I don't like)

The problem is: the 1Password extension on the second instance requires a full password to be unlocked where the one on the first instance asks me the fingerprint. I guess that the 1Password desktop cannot establish two connections to a single "application" and two instances of an application anyway belong to the same application.

  1. Is this an intended behavior?
  2. Can Chrome Beta (https://www.google.com/chrome/beta/) satisfy my requirement? (or does 1Password establish a new connection to the Chrome Beta?)

1Password Version: 8.10.4
Extension Version: 2.10.0
OS Version: macos 13.3
Browser:_ Chrome

Comments

  • Joy_1P
    Joy_1P
    1Password Alumni
    Options

    Hey @jinux_go, to unlock the extension with Touch ID, the app integration feature has to be working. For the app integration feature to work, both the 1Password app and your browser have to be installed in the /Applications folder. If either the 1Password app or your browser are installed outside of the /Applications folder, our communication protocols won't be able to properly verify the browser's code signature. You'd still be able to use the app and extension, but they will not communicate or connect.

    It sounds like one instance of Chrome is installed in /Applications, and Touch ID can be used to unlock the extension from there. That said, it also sounds like the second instance of Chrome is installed in a separate directory, and Touch ID does not work to unlock the extension from there. If that is truly the case, then this would be expected behavior.

    I would recommend moving the second instance of Chrome into the /Applications folder if you can. Alternatively, if you do not want to use a separate profile in Chrome, you can use another browser with 1Password. You will be able to unlock the extension in that browser with Touch ID as long as that browser is installed in the /Applications folder.

    I hope this helps. If I've misunderstood the situation, please let me know.

  • jinux_go
    jinux_go
    Community Member
    Options

    Thank you for your responding.
    Unfortunately, the second instance of Chrome is launched from the original /Applications/Google Chrome.app. More accurately, the command line I used to launch the second instance is this: open -na 'Google Chrome' --args --user-data-dir="$separateDataDir", where separateDataDir is not ~/Library/Application Support/Google/Chrome.

  • jinux_go
    jinux_go
    Community Member
    Options

    To avoid ambiguity, let's call the Chrome execution with unmodified --user-data-dir, Chrome:default and the one with modified --user-data-dir, Chrome:custom.

    I have experimented various scenarios. TL;DR: Chrome:custom never has a chance to establish the connection to the desktop app.

    Scenario 1 (this is my typical setup): Launch Chrome:default from Spotlight and then launch Chrome:custom from open command
    => Chrome:default connects. Chome:custom doesn't.

    Scenario 2: Launch Chrome:default from open command and then launch Chrome:custom from open command
    => Same. It seems it is nothing to do with the open command.

    Scenario 3: Launch Chrome:custom from open command.
    => No connection

    I assume the non-default --user-data-dir is the culprit...?

  • jinux_go
    jinux_go
    Community Member
    Options

    Another clue: right-click context menus of the extension from both executions show different items!

    Chrome:default:

    Chrome:custom:

  • jinux_go
    jinux_go
    Community Member
    Options

    DevTools console of Chrome:custom's 1Password extension prints:

  • jinux_go
    jinux_go
    Community Member
    Options

    @Joy_1P In case of not being notified...

  • jinux_go
    jinux_go
    Community Member
    Options

    The difference in menu items had nothing to do with the original issue. "Lock" and "Save login" appears only when the 1Password extension is unlocked.

  • jinux_go
    jinux_go
    Community Member
    edited May 2023
    Options

    Luckily enough, I have fixed it 😀. The culprit was the native messaging manifest file. 1Password desktop (it seems) installs the manifest file at the predefined path: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.1password.1password.json, which is under the default --user-data-dir. Since the second instance's --user-data-dir is non-default, there is no one to install the manifest there. The absence of the manifest is the direct reason for the extension being unable to connect to the desktop app.

    So, I manually copy-pasted the manifest to the proper location.
    The issue isn't a bug at all in the first place. My non-trivial and custom configuration is the thing.

  • steph.giles
    steph.giles
    Options

    Hey @jinux_go,

    I am so sorry for the delay in our reply.

    Thank you for the detailed update, I'm glad you were able to get things back on track.

    Let us know if there is anything else we can help with at all.

This discussion has been closed.