`hide-preferences-window` Preventing Preferences Window from Opening

[RaspberryKitty1]

As mentioned in #1983, the hide-preferences-window class is not being removed as expected.
This issue persists, preventing the Preferences window from appearing. As a result, users cannot
access settings or the "Restore Messages" popup.

Steps to Reproduce:

1. Open Caprine.
2. Attempt to access the Preferences window.
3. Observe that the Preferences window does not appear.

Expected Behavior:
The Preferences window should appear when accessed, allowing users to adjust settings
or restore messages.

Actual Behavior:
The Preferences window does not appear due to the hide-preferences-window class being incorrectly applied.

Temporary Workaround:
Users can manually remove the hide-preferences-window class using the following steps:

1. Press Ctrl+Shift+I to open the Inspector.
2. Locate and select the relevant HTML element.
3. Remove the hide-preferences-window class.

This workaround allows the Preferences window to appear but is not an ideal solution.

Environment:

• Caprine version: 2.60.3

Tested Operating Systems:

• Windows 11
• Debian 12
• Arch Linux

Additional Context:
This issue remains unresolved despite being flagged previously. A permanent fix to remove
or manage the hide-preferences-window class properly is needed.

[Polda18]

We shouldn't be required to remove the class manually using a Web Dev Tools hack. This issue should be resolved. From what I know, Caprine uses Chromium engine to render the Messenger app. I have no idea why the class isn't removed properly, it should work flawlessly in Chromium.

[mquevill]

We shouldn't be required to remove the class manually using a Web Dev Tools hack. This issue should be resolved. From what I know, Caprine uses Chromium engine to render the Messenger app. I have no idea why the class isn't removed properly, it should work flawlessly in Chromium.

If Caprine was only displaying the Messenger website, this would not be an issue. The hide-preferences-window class is added by Caprine to allow for additional capabilities to modify some of the settings (e.g. when toggling ) without the user seeing the preferences window being opened. The issue is that the selector that is used to monitor whether the preferences window is open or closed often changes when Messenger changes on the back-end. There are also often different versions of the website that different users get, which makes it hard to debug.

[mquevill]

I'm wondering if users have different interface versions. If someone is still having this issue on v2.60.3, could you run the following steps?

Open messenger.com and open the preferences window (remove hide-preferences-window class if it's already there)
In the web tools console, run:
document.querySelectorAll('.x1n2onr6.x1ja2u2z.x1afcbsf.x78zum5.xdt5ytf.x1a2a7pz.x6ikm8r.x10wlt62.x71s49j.x1jx94hy.x1g2kw80.xxadwq3.x16n5opg.x3hh19s.xl7ujzl.x1kl8bxo.xhkep3z.xb3b7hn.xwhkkir.x1n7qst7.x17omtbh:has(.x1l90r2v.x1swvt13.x1pi30zi)')
which is the selector that Caprine is currently using to determine if the window is open.

If it returns an empty list, that would explain why hide-preferences-window is not being removed.
An alternative selector to try is
document.querySelectorAll('[role="dialog"]')
I would then want to know what the class/selector is for that element (what that command returned). I would hesitate to use [role="dialog"] as the selector since it might be used by other modal elements too.

If this is an issue where users are getting different versions of the back-end, it's going to be more complicated to implement, but not sure if that's the case yet.

[RaspberryKitty1]

I'm wondering if users have different interface versions. If someone is still having this issue on v2.60.3, could you run the following steps?

Open messenger.com and open the preferences window (remove hide-preferences-window class if it's already there) In the web tools console, run: document.querySelectorAll('.x1n2onr6.x1ja2u2z.x1afcbsf.x78zum5.xdt5ytf.x1a2a7pz.x6ikm8r.x10wlt62.x71s49j.x1jx94hy.x1g2kw80.xxadwq3.x16n5opg.x3hh19s.xl7ujzl.x1kl8bxo.xhkep3z.xb3b7hn.xwhkkir.x1n7qst7.x17omtbh:has(.x1l90r2v.x1swvt13.x1pi30zi)') which is the selector that Caprine is currently using to determine if the window is open.

If it returns an empty list, that would explain why hide-preferences-window is not being removed. An alternative selector to try is document.querySelectorAll('[role="dialog"]') I would then want to know what the class/selector is for that element (what that command returned). I would hesitate to use [role="dialog"] as the selector since it might be used by other modal elements too.

If this is an issue where users are getting different versions of the back-end, it's going to be more complicated to implement, but not sure if that's the case yet.

Thanks for the detailed steps! I ran both selectors, and they both seem to identify the same element successfully (as shown in the attached screenshot). However, for some reason, the hide-preferences-window class isn’t being removed. I’m not sure why this is happening yet.

This issue only seems to affect me on fresh installs of Caprine. Once I run the web tools in Caprine and manually address the preferences window, the issue resolves itself and doesn’t come back, even after rebooting or relaunching the app.

It might be worth exploring if this is a timing issue (e.g., the class is being checked or modified before the preferences window is fully initialized) or if there’s some additional dependency that’s interfering during the first launch on fresh installs.

[stuckj]

Also affects me. Yep, the selector properly finds the div for the preferences dialog in a brave window (chromium based).

However, I definitely see this every time in caprine on ubuntu (have for a long time now). I always just do the hack to get it working if I restart caprine. But, it is annoying.

Perhaps this is a race condition between searching for the div and the preferences window actually being displayed?

[jcogilvie]

Windows 11, 2.60.3. Empty list when prefs dialog is closed; the elements match when the prefs dialog is opened:

while opened:

document.querySelectorAll('[role="dialog"]')
NodeList [div.x1n2onr6.x1ja2u2z.x1afcbsf.x78zum5.xdt5ytf.x1a2a7pz.x6ikm8r.x10wlt62.x71s49j.x1jx94hy.x1g2kw80.…]
document.querySelectorAll('.x1n2onr6.x1ja2u2z.x1afcbsf.x78zum5.xdt5ytf.x1a2a7pz.x6ikm8r.x10wlt62.x71s49j.x1jx94hy.x1g2kw80.xxadwq3.x16n5opg.x3hh19s.xl7ujzl.x1kl8bxo.xhkep3z.xb3b7hn.xwhkkir.x1n7qst7.x17omtbh:has(.x1l90r2v.x1swvt13.x1pi30zi)')
NodeList [div.x1n2onr6.x1ja2u2z.x1afcbsf.x78zum5.xdt5ytf.x1a2a7pz.x6ikm8r.x10wlt62.x71s49j.x1jx94hy.x1g2kw80.…]

[stuckj]

I imagine it should be empty while preferences is closed if this is intended to search for the preferences window.

Where in the code is this? I was going to see if I could find a race condition, but when searching for document.querySelectorAll I find three matches and none of them look like they're for preferences. I see one for video, one for left sidebar, and one for chatsIcon. I expected to find something for preferences. Maybe I'm looking for the wrong thing?

https://github.com/search?q=repo%3Asindresorhus%2Fcaprine+document.querySelectorAll&type=code

[stuckj]

Nvm, I found it:

caprine/source/browser.ts

Line 222 in 2ba6371

if (!isPreferencesOpen()) {

[stuckj]

I'll continue debugging when my kids are in bed. But, after setting an attribute breakpoint on the HTML element and some sleuthing I can say that in my case the hide-preferences-window class is being applied after this line runs and is never removed:

caprine/source/browser.ts

Line 766 in 2ba6371

const zoomFactor = await ipc.callMain<undefined, number>('get-config-zoomFactor');

Nah, nevermind. Must be happening in parallel somewhere. Not sure why the operation that's triggering it isn't breaking on the DOM modification.

[stuckj]

For my case, this line runs which adds the class (presumably to change mute notifications):

caprine/source/browser.ts

Line 249 in 2ba6371

const shouldClosePreferences = await openHiddenPreferences();

But, the corresponding line to close preferences here is never run:

caprine/source/browser.ts

Line 667 in 2ba6371

if (removedRecords.length > 0) {

So, the class is never removed and when I manually remove the class the preferences window is, in fact, still open. Which is what blocks many things (I can't scroll back history, blah, blah, blah).

If I can figure out why I'll submit a PR. Though, it's a little hard debugging this. I'm not familiar with debugging Electron apps. It thankfully does show source code when I hit DOM breakpoints, but I'm not actually sure how I can make code edits that aren't blown away with a refresh. If I can figure out the broken code path I'll see if I can just build it locally and run it.

[stuckj]

Turns out debugging an electron app is basically the same as any node app. :-P I couldn't reproduce this when running locally, but can reproduce it every time in the production app.

The call here never returns:

caprine/source/browser.ts

Line 654 in 2ba6371

await elementReady(selectors.preferencesSelector, {stopOnDomReady: false});

It gets to that line, but then never gets here after the openPreferences call:

caprine/source/browser.ts

Line 227 in 2ba6371

return true;

What I noticed in the production app is that the selector is different. It looks like this:
"div[role=dialog][class="x1n2onr6 x1ja2u2z x1afcbsf x78zum5 xdt5ytf x1a2a7pz x6ikm8r x10wlt62 x71s49j x1jx94hy x1g2kw80 xxadwq3 x16n5opg x3hh19s xl7ujzl x1kl8bxo xhkep3z xb3b7hn xwhkkir xeb55yp x17omtbh"]"

That is NOT in the DOM based on document.querySelector. Which is why that call to elementReady never returns and the class is never removed. Also might explain extra CPU I see from caprine.

Running locally the class is as you stated above @mquevill. And, that's in the DOM so gets removed.

It looks like that selector was only just changed 3 weeks ago by you @mquevill.

Turns out I don't have auto-update for this app since it's just installed from a deb so I tried grabbing the latest (2.60.3) and installing it. That didn't work. BUT, I looked in "About Caprine" and it shows 2.60.1. So...that's weird.

I did an apt remove --purge caprine and re-installed. Still broken. The selector is still the incorrect one. Perhaps the latest build doesn't actually have those changes?

I do notice the comment about the selector being very fragile. It might be nice to have an option to NOT have hidden preferences. Honestly, I could care less if it pops up a settings window for a second to change a setting if it avoids stuff like this.

I'm happy to submit a PR if there's interest and I can figure it out. Christmas vacation just started for me so I have a little free time.

[stuckj]

It's still broken with a locally generated deb with npm run dist:linux. So...that's weird. The AppImage version works. I need to run it with --no-sandbox due to permissions on electron though.

Any ideas on why this seems to persist even after update. Is there JS cached somewhere that's being used instead of the latest code?

[stuckj]

Figured it out. I had an older flatpak version installed that was getting used instead of the apt version. Purged them both and killed the configs for the deb (in ~/.config/Caprine) and flatpack (in ~/.var/app/com.sindresorhus.Caprine/config/Caprine) and restarted.

On first open it incorrectly left hide-preferences-window on after I logged in. I think this is because of the dialog prompting for the code to unlock old messages. After quitting and restarting several times it works fine now though.

So, in summary, to fix I'd recommend:

• Make sure you don't have multiple installs :-P
• Update to the latest version.
• On first login it will mess up. Do the hack to remove the class.
• Thereafter it should be fine (assuming there is no new dialog on login).

I'm gonna see how hard it is to add an option to bypass the whole hidden settings thing (it can be off by default). I don't feel like it's worth the hassle.