Can't save settings

[tomclark]

General information

• Operating system + version: macOS Monterey 12.4
• Browser + version: Google Chrome 102.0.5005.61
• Information about the host app:
  • How did you install it?
    Installed with Homebrew
  • If installed an official release, put a version ($ browserpass --version): v3.0.8
• Information about the browser extension:
  • How did you install it?
    Via the Chrome Web Store
  • Browserpass extension version as reported by your browser:
    3.7.2

---

If you are getting an error immediately after opening popup, have you followed the [Configure browsers] - N/A

---

Exact steps to reproduce the problem

1. Right-click icon in browser menu

2. Choose options

3. The dialog displays, but there's no option to save preferences:

(I've ticked these boxes. How do I now get it to save those options? Clicking the X to close the dialog loses the changes).

What should happen?

I should be able to save settings.

What happened instead?

I need to change settings to a) enable OTP, and b) give a custom path to the GPG binary (I'm on an M1 Mac, so need to give it: /opt/homebrew/bin/gpg).

Per the screenshot, there's no option to save. I've been using the plugin for ages on lots of browsers and I can't for the life of me remember whether there ever was a save button in the preferences.

I've discovered from the readme that I can put a .browerpass.json in the root of my .password-store folder, and in doing so, I'm able to get the plugin to pick up the correct path to the binary, but it doesn't seem to pick up the enableOTP field. My .browserpass.json file looks like this:

{
  "enableOTP": true,
  "gpgPath": "/opt/homebrew/bin/gpg"
}

As I say, the gpgPath is now being picked up correctly, but it still doesn't parse the OTP field in my password files. I've looked at the code, and as far as I can tell enableOTP is the correct name for the setting, but it's not working.

It's always worked until now - what am I doing wrong?

Your advice very much appreciated from an ever-grateful user. :-)

[erayd]

This looks like a bug in Chrome v102, and not a Browserpass bug. I've just tested it on Monterey 12.4, and can confirm that it works perfectly on Chrome v101, but v102 fails to fully render the options dialog. The failure point appears to be inconsistent.

This screenshot is v101:

These two are both v102:

It appears there are two separate problems here. In the first screenshot, the options body HTML does not appear to be injected by Chrome at all. I cannot currently think of a way to work around this. Repeatedly reloading the options screen does eventually seem to result in the second screenshot.

In the second screenshot, the full markup of the options box is injected, but is displayed inside an iframe container (which itself is inside a shadow root) that inherits the wrong height from its ancestor container. This can be worked around on a temporary basis by using the developer tools element inspector. Right-clicking the options popup title bar, then selecting 'inspect', will take you to approximately the location in the screenshot below. You may need to expand some stuff in order to locate the precise element that needs to be tweaked.

@maximbaz Hopefully Google fixes this one quickly, but if not, we may need to consider moving our options into a separate tab, rather than using the default options mechanism as we do currently.

[maximbaz]

Ack, and thanks for the investigation!

[erayd]

I have now also looked into enableOTP not being picked up when set in .browserpass.json - that bit is definitely our bug!

[erayd]

I have now found a method to reliably get from this:

to this:

To do so, simply switch to another tab while the options dialog is open, then switch back. This seems to trigger the body content to actually load. You'll still need the above inspector workaround in order to reveal the buttons.

[tomclark]

I have now found a method to reliably get from this:

to this:

To do so, simply switch to another tab while the options dialog is open, then switch back. This seems to trigger the body content to actually load. You'll still need the above inspector workaround in order to reveal the buttons.

Hey, thanks for your super quick reply and investigation. I didn't mention the odd rendering of the dialog where you just get the header - I thought that was something else my side - but I should've done since I'd noticed that too. I found that I could make it go away/render properly (or at least properly without the save button) by switching to another space and switching back again. Seems to get rendered properly after that.

FWIW, I'm seeing the same issue with Brave (Version 1.39.111 Chromium: 102.0.5005.61), which I guess makes sense given the Chromium version.

Thanks ever so much for your help - and your efforts on the plugin more generally. Per your instructions, I used the devtools to increase the height of the dialog and can now see the save and clear usage buttons. I've now set the settings correctly and saved. Perfect!

Not sure what to do with this ticket. I guess you'll want to track the issue, but I have a resolution for my immediate problem. I'll leave it open and let you guys decide whether to close it. Thanks again! 👍

[erayd]

Not sure what to do with this ticket. I guess you'll want to track the issue...

Yep, I think I'd prefer to keep this one open for now.

[Loki-Afro]

is there also an open bug on chromium's side of things?

[haji-ali]

I am also experiencing the same issue on Firefox (not being able to save any settings).

[maximbaz]

Could anyone confirm please whether this is still an issue in 3.10.2+, especially given an improvement in #373 ?

[patgmiller]

Could anyone confirm please whether this is still an issue in 3.10.2+, especially given an improvement in #373 ?

I tried checking this in my chrome version, however I'm on a much newer build (see below). I did try to duplicate the issue before the improvement in #373, but I could not duplicate the issue; so it's possible that Chrome fixed their issue in a later build.

Chrome is up to date
Version 135.0.7049.42 (Official Build) (arm64)
macOS: Sequoia 15.3 (24D60)

[maximbaz]

I had the same suspicion, I also tried before #373 and it wasn't reproducible, but I'm on Linux and I'm not sure it was macOS specific or not.

Will close the issue, but if anyone comments that this is still reproducible, will reopen 🙂