`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: https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L222

[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: https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L766~

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): https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L249

But, the corresponding line to close preferences here is never run: https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L667

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: https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L654

It gets to that line, but then never gets here after the openPreferences call: https://github.com/sindresorhus/caprine/blob/2ba637137839e41081ab3fe63b1a1ca609a35ac4/source/browser.ts#L227

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.

[stuckj]

PR here for new setting: https://github.com/sindresorhus/caprine/pull/2269

[wbraswell]

@sindresorhus So will this fix be included in the next Caprine release??? Because it is basically unusable at this point...

[charrion]

Not to mention the only workarounds are for people experienced with coding. There are zero solutions available for the average user.

You can't make a user friendly interface if you're not friendly to users.

[stuckj]

The point of the #2269 PR I have above is to make it easier for non-developers. You can just flip a setting and then it won't be a hidden preferences window, but a visible one that you can close to at least be able to use the app.

[wbraswell]

@stuckj Ah okay so your PR doesn't actually fix the problem directly, but it allows users to click a few buttons to achieve a temporary workaround solution, until such a time as the actual underlying problem is fixed by the main Caprine developers?

[stuckj]

Nope, it doesn't fix the problem. The problem is one that will likely continue to recur. @mquevill fixed it a few months ago, but Facebook continually makes changes so it will likely break again. Since Caprine is essentially just a fancy web wrapper around a webpage (messenger web) with some features added on top it can break when the webpage changes.

The feature causing the problem is the ability to configure certain messenger features from the caprine menu (which is outside the webpage). It applies the changes from the menu by popping up the messenger settings up and clicking whatever buttons needs to be clicked for each feature in the menu. The authors hid the dialog so it doesn't look ugly. But, when Facebook makes changes that prevent them from properly identifying whether the popped up dialog is actually the "settings" dialog then things break because caprine leaves that settings dialog up, but in a "hidden" state. That is what breaks all sorts of things (e.g., scrolling back in the history). Because there is a dialog you can't see that's blocking things.

My fix just let's you check a checkbox to tell Caprine to stop hiding that dialog. It will still pop it up to apply settings, but it will be visible. When things are working it'll just look like a blip that quickly appears and disappears. When things are broken, as they are for you now, the dialog will remain up. But, you can just close it and go on your way. Some of the settings from the Caprine menu might, perhaps, not properly apply. But...at least messenger will work. :-P

An alternative is just open messenger.com in your browser. Basically, Caprine is just a wrapper around a mini chrome browser that shows messenger.com so it won't be much different. :)

[wbraswell]

@stuckj Okay great, thanks for the very helpful explanation!

[SilverSaw]

It is broken again @stuckj could you please explain for the avg user how to rebuild the client with your fix, or share it with git link? It seems like nobody is going to merge this workaround?

[stuckj]

I don't have such instructions.

I was new to development with electron apps. I ran caprine from a git checkout in development mode after some research into how to develop an electron app and made the change and tested it from there. After making the PR, I switched back to running the app from a normal install as it's definitely not convenient to run it from code (and you can't setup autostart and such). I'm not sure how to package an electron app into an installable package and don't currently have the time or desire to research it.

I'm actually giving up on this wrapper. The last commit was 6 months ago and there's radio silence from any developer with the ability to merge changes. Given how easy it is to just open messenger in a browser, I'm just going to switch to that. Below I've got some instructions on how to do that in case you're not familiar.

I use brave browser which is chromium-based. I believe you should be able to do the same thing from chrome. Here's how you would do it in Ubuntu (similar for other linux flavors). The terminal instructions should work similarly if you're using Mac or Windows.

Run from the terminal:

Brave Browser

brave-browser --app=https://www.messenger.com

Chrome

google-chrome --app=https://www.messenger.com

Make a desktop launcher

This allows you to start the app from your normal menus or search in your window manager (e.g., press the windows button and start typing the app name...Messenger in this case).

From a terminal, use nano (or your favorite text editor) to create a file: nano ~/.local/share/applications/messenger.desktop

Set the contents to this and save it:

[Desktop Entry]
Name=Messenger
Exec=brave-browser --app=https://www.messenger.com
Terminal=false
Type=Application
Icon=facebook-messenger
Categories=Network;Chat;

NOTE: Use google-chrome instead of brave-browser if you're using chrome instead of brave.

[Sp3EdeR]

As a slightly less annoying workaround that needs no new Caprine version, do:

1. Click the File -> Caprine Settings -> Advanced -> Custom Styles menu point
2. Your default text editor opens a text file.
3. Paste the following text into an empty line within this text:

   html.hide-preferences-window div[class="x9f619 x1n2onr6 x1ja2u2z"] > div:nth-of-type(3) > div > div {
       display: block !important;
   }
   

After every startup, and when using a built-in settings tweaking option, the settings window may be shown by Caprine, but you can close it. Depending on what site is served to you, Caprine may use different values in the class="..." section for you, in which case the above will not help. Someone better versed in Caprine's behaviour may be able to provide a more versatile selector in that case.

[SilverSaw]

@Sp3EdeR Thanks, appreciate it!

[profucius]

This fixed the issues I was experiencing too!

[dagerga]

@Sp3EdeR Fixed it for me, thanks!

[MrFlacko]

html.hide-preferences-window div[class="x9f619 x1n2onr6 x1ja2u2z"] > div:nth-of-type(3) > div > div { display: block !important; }

Yeah this does work. However when opening Messenger it still shows the preferences window each time when starting, requiring it be manually closed. I tried for quite a while to stop this from showing initially but couldn't figure it out.

If someone can recommend a better fix that would be wonderful, I'm running on caprine 2.60.3

I can reproduce it by doing Ctrl+Q to quit out of Caprine

This issue should also affect 2.58.0 - 2.60.3 also if it helps anyone, I just added it to ~/.config/Caprine/custom.css

[ShawnFumo]

Thanks, the CSS helped for mine as well. Not sure if I'll keep this considering it is dead, but it does have keyboard shortcuts at least, which the default messenger "app" on windows doesn't have. Anyone know of any other alternatives/forks out there?