Whatsapp update available

[LiBOSS-CZ]

Steps to reproduce

1. Add Whatsapp account
2. Reload all services/Restart Rambox/Restart computer

Expected behavior

Once click to update Whatsapp.

Actual behavior

Nearly every restart of Rambox you have to update Whatsapp. (not everytime, but 75%) I am using two Whatsapp account.

I thinks it is starts to appeared after correcting the Issue #72

ENVIRONMENT

Rambox-OS: 0.5.18 OS: Windows 10 Pro 1809 Arch: x64 BuildVersion: 0172bec

[TheGoddessInari]

I haven't been able to reproduce this, WhatsApp Web says it's version 0.3.1846. WhatsApp, why do you hate us so?

[LiBOSS-CZ]

Maybe it is because of two accounts logged in simultaneously. I have the same version as you. Before update it is same version as after update.

[wefalltomorrow]

I've been having that messages on and off for months, just click it and refresh to make it go away temporarily.

[M0UL]

I've been having that messages on and off for months, just click it and refresh to make it go away temporarily.

same here

[LiBOSS-CZ]

I've been having that messages on and off for months, just click it and refresh to make it go away temporarily.

Yes, I know, that you just click, but you do not want to do it almost every start of Rambox (for me twice). Latest test version with whatsapp fix and new electron does not help.

[TheGoddessInari]

Don't suppose this is fixed on master?

If WhatsApp is freaking out on their end because someone's using multiple WhatsApp accounts, I'm not sure what can be done. None of the storage is shared, the tabs can't communicate with each other, so it's entirely on their end.

I don't seem to've asked before, but does this occur at all on other apps, on Android with features like dual messenger or sandboxing?

Maybe I'm overthinking it and there'd be some way to simply block the notice, since if you're on the web version, presumably there isn't an update unless you've been running a single session forever.

[LiBOSS-CZ]

On Android I do not have any problems with dual Whatsapp. Normally working as expected. As you said, it could be WhatsApp-side problem, but right now I have tried Rambox CE and this issue does not occured.

[TheGoddessInari]

I've pushed a commit to testing that tries to see if we can remove the slowed timer blacklist from WhatsApp as per @JakobStruye's comment in #42.

This could possibly affect #31 too, so I'd like testing on WhatsApp to make sure it doesn't regress as well as to see if it fixes this.

I'll test as much as I can, but for some reason I wasn't getting hit with these issues in the first place.

[JakobStruye]

If you want to confirm quickly whether it could be a fix for any WhatsApp issues, you could add something like

if (func_args.length > 0) {
    console.log("Now properly passing arguments in setTimeout");
}

to the override of setTimeout.

If that's never logged, there's no chance that fix will change anything for WhatsApp.

[TheGoddessInari]

Also a good thing to think of. It logs it a number of times, on both login and when loading normally. The source debugger's definitely working better than in electron 1.x, but I'm still somewhat mystified by it, so I can't reasonably say that it will or won't fix X, just that it's worth testing.

[LiBOSS-CZ]

I have tried build 204 - e311167 with same bad result:-(. I have noticed, that second whatsapp account is loading slower than the first one and it does not matter on tab order. Issues does not occur if I put Whatsapp accounts as 1st and 2nd tab. 1st an 3rd sometimes for the second account. With Rambox CE it is working as 1st and 5th tab. It seems to me that it has something to do with duration of loggin in.

[joe776]

Just FYI, happens for me with just a single Whatsapp account (I do have 3 other messengers however). Macbook Pro Mid'14 with lots of things running, so not the fastest machine.

[LiBOSS-CZ]

Now I am running WA and WA Bussiness account with same behaviour. I do not think that this is CPU power related. I am using it on i7 7700HQ with 16GB RAM and NVMe SSD.

[TheGoddessInari]

Since this appears to affect everyone but me, use the developer tools and see if you can come up with a simple JS or CSS to hide the update notification and I'll see if I can include it.

[joe776]

Just tried to have a look in your preview build, but that doesn't really work for me. I guess it clashes with the "old" Rambox version (there were also some exceptions in the dev console). In the old version (pre-fork) i only get to the iframe which contains Whatsapp, but cannot access anything within it So maybe this doesn't happen for you, Inari, because you do not use the "old" version of Rambox?

[TheGoddessInari]

I don't use the upstream version of Rambox, no.

If anyone wants this fixed for 0.5.18, which is ready-ish now except for this and #93, I'm going to need a lot more to go on than I have now.

Old data in the WhatsApp container will likely cause false-positives of problems, as stated many times. This is due to the design of WhatsApp. Other webapps tend to handle this situation themselves.

Containers/tabs can't talk with each other, so I'm not sure how two accounts could cause this, nor could I likely make two accounts myself. Opening the same account with two instances of WhatsApp Web for the same account definitely doesn't cause this for me.

WhatsApp has always been screwy with electron-based apps, and has been totally unresponsive to bug reports or requests of any kind in the last year.

[TheGoddessInari]

This should be resolved in 4aab913. If it's not, let me know and I can add a version override.

I'd prefer not to have to do that, of course, given that all of this is WhatsApp's fault for using bad User Agent string sniffing instead of feature detection.

[MatMaul]

It doesn't seem to be solved for me.

[TheGoddessInari]

As far as I can tell, it sometimes says this because it thinks that the version of Chrome in-use is too old, instead of letting Google handle Chrome updates. Since it's a redundant warning, and electron doesn't update as fast as WhatsApp likes, the best way to handle this would probably be to simply suppress that particular warning by default, but as it simply refuses(!) to pop up for me, I can't isolate the elements necessary to cleanly block it by default (without blocking anything else) using the CSS or JS as appropriate.

I used to block the useless "helper bar" at the bottom of Skype for the same reason because it simply wastes a fair amount of vertical space for no benefit, but they changed how things are arranged and there's nothing unique about it to block.

Lying about the version would require constant maintenance and they would possibly try to invoke features that the Electron version of Chromium simply doesn't have, since WhatsApp parses user agents instead of using proper feature detection, and totally ignores all reports sent to them, no matter the severity.

[TheGoddessInari]

The testing branch will currently be on Electron 5.0.0, which uses Chrome v73, which should be new enough for WhatsApp.

Let me know if you find any problems with electron 5 because it'll probably become the default if there aren't more wrinkles to iron out.

[MatMaul]

Confirmed, no more update nagging on testing branch :)

[LiBOSS-CZ]

I have tried on latest master (d42dc5c) also with Chrome v73, but still appears. It is appearing a lot less, but still appears (1 in 10 maybe). Now it seems to be OK. So hopefully is it resolved.

[LiBOSS-CZ]

This problem is back:-( Even with the lates Hamsket version 9cc1a71

[TheGoddessInari]

This is surreal. Chrome 76 is the latest release version (and as usual, I can't replicate).

I think the problem is...we have no idea what WhatsApp is actually demanding here. They're totally opaque about it, and refuse to answer any support tickets.

[LiBOSS-CZ]

I think, that problems is in two Whatsapp (I am using Whatsapp and Whatsapp Bussiness) account signing in simultaneously. Is any possibility how to delay singing in for one account?

[YerayAlonso]

I found a workaround: https://github.com/ramboxapp/community-edition/issues/2217#issuecomment-562023784

[TheGoddessInari]

@YerayAlonso Mind if I add that to official?

[francwalter]

I have it too, sometimes more often, sometimes not at all for a while, at the moment with my Windows 10 tablet and latest Hamsket nightly (though I think it is unrelated with Hamsket). When I tap the update button, I get that silly Update Google Chrome screen, so it doesnt help at all. I have to refresh and again it is, the update available screen. I use the beta WhatsApp where I can use up to 4 different Web-WhatsApp versions whithout need to be connected to my phone (a feature long available in telegram and new to whatsapp now, very useful, because it is very annoying to always refresh WhatsApp on my phone to have it on my tablet etc.).

I will live with this notification and will ignore it. Maybe I can get rid of it with some CSS in the settings. EDIT: no, that seems not possible, I cant get grip of that part of the window with the dev tools :(

I found a workaround: ramboxapp#2217 (comment)

This works neither, I put it in Custom JS part of the WA-service-settings. But anyway, if I try the developer tools and click the inspector (CTRL+SHIFT+C) the part with the "Update available" is not selectable and all the contacts neither, all the WA frame is not available for me, I dont know how to get grip of it.

... isolate the elements necessary to cleanly block it by default (without blocking anything else) using the CSS or JS as appropriate.

I dont know how to find it 😢

[francwalter]

I think it is related to that Beta, quite new now, must have some totally different CSS-Classes. That "_3O0po" Class is not in use obviously, that trick from YerayAlonso doesnt work anymore. I tried the ID "side" which I got from the "real" WA-Web-Version, but it is not known in Hamsket's WA. I thought with "side" I could slide to the bad ID with next-sibling or something like that, but if it is unknown I am over with my latin. I tried in DevTools things like:

for(i=1;i++;i==400) document.getElementsByTagName("DIV")[i].style.color = "red";

But this affects only all the Hamsket Window around the WA-content. No way to get to that.

If I only knew how to find the actual class or ID of that damned element with that damned "Update available". I guess there are several developers employed at Facebook just to make it harder to use WA in any other environment than they want to.

[DeLuke84]

With that piece of code, the span element which contains the 'Update available' message can be removed.

(() => { setTimeout(() => document.getElementsByClassName("_3z9_h")[0].remove(), 7000); })();

A better solution would be to have some kind of event handler instead of a timeout, which check's whether the page has been loaded.

Since I'm not a JS expert, I don't know how to do it.

[francwalter]

The class _3z9_h might be a randomly given classname, on my system it is unknown :( If I do in the console of the devtools some: document.getElementsByClassName("_3z9_h")[0] I can see that it is undefined.

its undefined and when I try to set the display of that element to none it is hence an error:

I cant get grip of the inner of the WhatsApp code, it is just a webview, where I cannot enter with the Developer Tools:

    <webview class="x-component x-component-default" src="https://web.whatsapp.com/"
        style="width:100%;height:100%;visibility:visible;" partition="persist:whatsapp_14" allowtransparency="on"
        autosize="on" webpreferences="nativeWindowOpen=yes,spellcheck=yes,contextIsolation=no" allowpopups="on"
        useragent="Mozilla/5.0 (Macintosh; Intel Mac OS X 15_6_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36"
        preload="./resources/js/hamsket-service-api.js" id="box-1050"></webview>