Whatsapp Web reports it needs chrome 60+ even though I have chromium 86

Question

Whatsapp Web reports it needs chrome 60+ even though I have chromium 86

Itai-Nelken opened this issue 3 years ago · comments

Homework

I looked at nativefier --help and https://github.com/nativefier/nativefier/blob/master/docs/api.md
I searched existing issues, open & closed. Yes, my bug is new.
I'm using the latest version available at https://github.com/nativefier/nativefier/releases

Bug description

my WhatsappWeb nativefier webapp is complaining that the chrome version isn't new enough even though I have chromium 87.

Steps to reproduce

Give your full nativefier command and its logs, with the --verbose flag, on a public site:

pi@Twisterpi4-ultra-4gb:~/Documents $ nativefier --arch=armv7l --tray --verbose https://web.whatsapp.com
Running in verbose mode! This will produce a mountain of logs and is recommended only for troubleshooting or if you like Shakespeare.

Performing async options post-processing.
Inferring user agent for electron 11.1.1 / linux
Grabbing electron<->chrome versions file from https://atom.io/download/atom-shell/index.json
Inferring icon for https://web.whatsapp.com/ on linux
Inferring icon from store for https://web.whatsapp.com/ on linux
Allowed icon formats when building for linux: [ '.png', '.ico' ]
Inferring name for https://web.whatsapp.com/
Got 249 icons from gitcloud
Max icon match score: 1
Downloading https://nativefier.github.io/nativefier-icons/files/whatsapp.png
Fetched 3.5 kb page at https://web.whatsapp.com/
Inferred title: WhatsApp Web
Sanitized filename for WhatsApp Web : WhatsAppWeb
Got an icon from the page.
Writing 159.2 kb icon to /tmp/nativefier-17-54-2-iconinfer--2434-IBXu9tksPljI/icon.png
Associated electron v11.1.1 to chrome v87.0.4280.88
Given chrome 87.0.4280.88 on linux, using user agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Preparing Electron app...
Copying electron app from /usr/lib/node_modules/nativefier/app to /tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo
Writing app config to /tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo/nativefier.json
No files to inject, skipping copy.
Updating /tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo/package.json 'name' field to whatsappweb-nativefier-d40211

Converting icons...
Building for Linux and icon is already a .png, no conversion needed
Copying icons if necessary
Copying icon /tmp/nativefier-17-54-2-iconinfer--2434-IBXu9tksPljI/icon.png to /tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo/icon.png

Packaging... This will take a few seconds, maybe minutes if the requested Electron isn't cached yet...
  electron-packager Electron Packager 15.2.0
  electron-packager Node v15.8.0
  electron-packager Host Operating system: linux 5.10.11-v7l+ (arm) +0ms
  electron-packager Packager Options: {"arch":"armv7l","asar":false,"darwinDarkModeSupport":false,"dir":"/tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo","electronVersion":"11.1.1","icon":"/tmp/nativefier-17-54-2-iconinfer--2434-IBXu9tksPljI/icon.png","name":"WhatsAppWeb","out":"/home/pi/Documents","overwrite":true,"platform":"linux","targetUrl":"https://web.whatsapp.com/","tmpdir":false,"win32metadata":{}} +2ms
  electron-packager Target Platforms: linux +1ms
  electron-packager Target Architectures: armv7l +1ms
  electron-packager Inferring appVersion from version in /tmp/nativefier-17-54-2-app--2434-2YfMkOSuXbCo/package.json +0ms
  electron-packager Application name: WhatsAppWeb +25ms
  electron-packager Target Electron version: 11.1.1 +1ms
  electron-packager Ignored path regular expressions: [
  '/package-lock\\.json$',
  '/yarn\\.lock$',
  '/\\.git($|/)',
  '/node_modules/\\.bin($|/)',
  '\\.o(bj)?$',
  '/tmp/electron-packager'
] +0ms
  electron-packager Downloading Electron with options {"platform":"linux","arch":"armv7l","version":"11.1.1","artifactName":"electron"} +0ms
Packaging app for platform linux armv7l using electron v11.1.1
  electron-packager Creating /home/pi/Documents/linux-armv7l-template +12ms
  electron-packager Extracting /home/pi/.cache/electron/af55cf85e08a7252cdf4740b3b9843bcd6ee0d88d78fc42ee0de0a928079a3b5/electron-v11.1.1-linux-armv7l.zip to /home/pi/Documents/linux-armv7l-template +2ms
  electron-packager Initializing app in /home/pi/Documents/WhatsAppWeb-linux-armv7l from /home/pi/Documents/linux-armv7l-template template +0ms
  electron-packager Ignored paths based on the out param: [
  '/home/pi/Documents/WhatsAppWeb-darwin-x64',
  '/home/pi/Documents/WhatsAppWeb-darwin-arm64',
  '/home/pi/Documents/WhatsAppWeb-linux-ia32',
  '/home/pi/Documents/WhatsAppWeb-linux-x64',
  '/home/pi/Documents/WhatsAppWeb-linux-armv7l',
  '/home/pi/Documents/WhatsAppWeb-linux-arm64',
  '/home/pi/Documents/WhatsAppWeb-linux-mips64el',
  '/home/pi/Documents/WhatsAppWeb-mas-x64',
  '/home/pi/Documents/WhatsAppWeb-mas-arm64',
  '/home/pi/Documents/WhatsAppWeb-win32-ia32',
  '/home/pi/Documents/WhatsAppWeb-win32-x64',
  '/home/pi/Documents/WhatsAppWeb-win32-arm64'
] +5s
  electron-packager Renaming electron to WhatsAppWeb in /home/pi/Documents/WhatsAppWeb-linux-armv7l +154ms

Finalizing build...
App built to /home/pi/Documents/WhatsAppWeb-linux-armv7l , move it wherever it makes sense for you and run the contained executable file (prefixing with ./ if necessary)
Menu/desktop shortcuts are up to you, because Nativefier cannot know where you're going to move the app. Search for "linux .desktop file" for help, or see https://wiki.archlinux.org/index.php/Desktop_entries
pi@Twisterpi4-ultra-4gb:~/Documents $

Expected behavior

I expected the page with the QR code asking you to sign in to appear.

Actual behavior

it opened a page asking me to use chrome 60+

Debug info
It did work untill a few days ago.
I don't know if it helps, but before updating nativefier I got this when packaging whatsapp web (same error when starting the app though):

Unable to infer chrome version for user agent, using 87.0.4280.67

I installed/updated nativefier like this:

pi@Twisterpi4-ultra-4gb:~ $ sudo npm install -g nativefier --arch=armv7l
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

added 2 packages, removed 32 packages, changed 269 packages, and audited 272 packages in 1m

17 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm notice 
npm notice New patch version of npm available! 7.5.1 -> 7.5.3
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.5.3
npm notice Run npm install -g npm@7.5.3 to update!
npm notice 
pi@Twisterpi4-ultra-4gb:~ $

not using sudo caused it to fail because it didn't have the right permissions.
I did try using the --honest option but I got the same result.

The error:

My chromium version:

whatsapp web does work in chromium:

Context

Nativefier: 42.2.1
Node.js: v15.8.0
Npm: 7.5.1
OS: TwisterOS 1.9.9 (based on RPiOS 32bit) armhf running on a RaspberryPi 4b 4gb.
Is it a regression? I don't know.

Anirudh Haritas Murali · Answer 1 · Thu Feb 11 2021 02:27:07 GMT+0800 (China Standard Time)

I have the same issue, running on Arch Linux (kernel 5.10.14-arch1-1), with whatsapp-nativefier installed from the AUR

robocopkaka · Answer 2 · Thu Feb 11 2021 04:22:21 GMT+0800 (China Standard Time)

Same issue. Running on Ubuntu 20.04

Itai Nelken · Answer 3 · Mon Feb 15 2021 21:21:25 GMT+0800 (China Standard Time)

I made a whatsapp web nativefier webapp on MacOS (intel) and it works perfectly fine.

Itai Nelken · Answer 4 · Wed Feb 17 2021 00:40:55 GMT+0800 (China Standard Time)

I packaged a linux armv7l nativefier whatsapp web webapp on my mac and it works perfectly fine!
Maybe its something to do with the user agent? I did try using nativefiers option to use a different user agent, but it didn't work.

robocopkaka · Answer 5 · Wed Feb 17 2021 01:08:00 GMT+0800 (China Standard Time)

I also tried using different user agents but kept running into the same issue

Itai Nelken · Answer 6 · Wed Feb 17 2021 01:21:13 GMT+0800 (China Standard Time)

I think the option to use a different user agent is broken.

Nilava Chowdhury · Answer 7 · Thu Feb 25 2021 14:38:31 GMT+0800 (China Standard Time)

i used programatic API to build and passed

 userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15', // will infer a default for your current system
  honest: false,

Also modified constants.js inside nativefier to use

exports.DEFAULT_ELECTRON_VERSION = '11.3.0';
exports.DEFAULT_CHROME_VERSION = '87.0.4280.141';

which made it work

Itai Nelken · Answer 8 · Fri Feb 26 2021 23:38:23 GMT+0800 (China Standard Time)

@nilava can you post the steps you followed for people like me who don't understand electron/javascript/typescript whatever etc. please?

Kartik Kushwaha · Answer 9 · Tue Mar 09 2021 15:25:56 GMT+0800 (China Standard Time)

@nilava Can you let us know where to edit the files as i can't figure out where constants.js is located.

Adam Weeden · Answer 10 · Wed Mar 10 2021 02:14:31 GMT+0800 (China Standard Time)

I've gotten this to work on OS X with the following caveat:

I was able to run it via nativefier --verbose https://web.whatsapp.com --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15"

HOWEVER: Since I originally tried running it without the user agent, it looks like WhatsApp will cache what it thinks your user agent was even between app rebuilds, so I had to run the following commands from a command line to start fresh with the app:

rm -rf ~/Library/Preferences/com.electron.whatsapp*
rm -rf ~/Library/Application\ Support/whatsapp*

Itai Nelken · Answer 11 · Wed Mar 10 2021 02:34:54 GMT+0800 (China Standard Time)

I've gotten this to work on OS X with the following caveat:

I was able to run it via nativefier --verbose https://web.whatsapp.com --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15"

HOWEVER: Since I originally tried running it without the user agent, it looks like WhatsApp will cache what it thinks your user agent was even between app rebuilds, so I had to run the following commands from a command line to start fresh with the app:
rm -rf ~/Library/Preferences/com.electron.whatsapp*
rm -rf ~/Library/Application\ Support/whatsapp*

I can confirm that works for me on MacOS 11.2.2 and on the latest TwisterOS (RPiOS) after removing ~/.config/whatsappweb*.

Itai Nelken · Answer 12 · Wed Mar 10 2021 04:24:01 GMT+0800 (China Standard Time)

UPDATE: I have to delete ~/.config/whatsappweb-nativefier*/Service\ Worker each time I want to run the app, also clicking the 'update' button on the banner that appears from time to time causes it to say it needs a newer chrome version (I'm using a safari user agent).

Adam Weeden · Answer 13 · Wed Mar 10 2021 06:36:06 GMT+0800 (China Standard Time)

Same is true for me as well (~/Library/Application\ Support/whatsapp-web-nativefier*/Service\ Worker/Database) @Itai-Nelken .

I'm trying to look into it and the best I can surmise is this: It loads the first time, but their javascript has some custom Electron detection, and saves a note for itself to block on the next reload. I have figured out how to prevent this from happening, but will need to get @ronjouch 's appetite for adding yet another cli flag.

It boils down to this: if we clear the serviceworker's storage every time the app loads, this issue goes away and still keeps you logged in (await session.clearStorageData({ storages: ['serviceworkers'] });) but I don't think we want to do that universally. @ronjouch what do you think?

Right now you can add --clear-cache to the app to have it clear EVERYTHING, which prevents the detection as well, but that means you have to log back in every time.

Also as a side note, is there a reason you prefer doing a nativefier version of the app over their desktop app @Itai-Nelken (which appears to also be based on Electron)?

Itai Nelken · Answer 14 · Wed Mar 10 2021 06:41:46 GMT+0800 (China Standard Time)

Also as a side note, is there a reason you prefer doing a nativefier version of the app over their desktop app @Itai-Nelken (which appears to also be based on Electron)?

@TheCleric the official desktop app isn't available for ARM.

Adam Weeden · Answer 15 · Wed Mar 10 2021 06:43:34 GMT+0800 (China Standard Time)

@TheCleric the official desktop app isn't available for ARM.

That's a good reason! 😆

robocopkaka · Answer 16 · Wed Mar 10 2021 06:47:51 GMT+0800 (China Standard Time)

Ubuntu also doesn't have a desktop version

Ronan Jouchet · Answer 17 · Wed Mar 10 2021 09:09:09 GMT+0800 (China Standard Time)

The best I can surmise is this: It loads the first time, but their javascript has some custom Electron detection, and saves a note for itself to block on the next reload. I have figured out how to prevent this from happening, but will need to get @ronjouch 's appetite for adding yet another cli flag.

It boils down to this: if we clear the serviceworker's storage every time the app loads, this issue goes away and still keeps you logged in (await session.clearStorageData({ storages: ['serviceworkers'] });) but I don't think we want to do that universally. @ronjouch what do you think?

Right now you can add --clear-cache to the app to have it clear EVERYTHING, which prevents the detection as well, but that means you have to log back in every time.

@TheCleric two thoughts:

At first glance I'm not super thrilled to bake WhatsApp-specific code in core Nativefier, it feels brittle and cat-and-mouse-y. Maybe it feels more like the job of an --injected script, that would be community-maintained by sharing updates here (or in a future grand nativefier-configs community-fueled repo enabling sharing / picking of recommended icons & configs & css & scripts).
That being said, rather than adding a WhatsApp-specific flag, is there a generic flag we could add, that would deal with this WhatsApp trick, as well as maybe other sites? Would a new --clear-serviceworkers [on-app-exit|on-first-page-load|on-each-page-load] flag make sense?
Other ideas?

Matthew Ruzzi · Answer 18 · Wed Mar 10 2021 11:34:17 GMT+0800 (China Standard Time)

I am working on nativefier-catalog, a catalog of nativefier apps with configs. If #1116 gets merged,the fix can be added as an injected gist link when WhatsApp gets added to apps.json. Another option would be for me to create a place to put userscripts directly in the nativefier-catalog repo instead of using gist urls.
https://github.com/mattruzzi/nativefier-catalog

Ronan Jouchet · Answer 19 · Wed Mar 10 2021 20:25:36 GMT+0800 (China Standard Time)

I am working on nativefier-catalog, a catalog of nativefier apps with configs. If #1116 gets merged,the fix can be added as an injected gist link when WhatsApp gets added to apps.json. Another option would be for me to create a place to put userscripts directly in the nativefier-catalog repo instead of using gist urls. mattruzzi/nativefier-catalog

@mattruzzi 🎉🎉🎉 great news! Before you write too much code, are you open to first have a discussion about it? (In the "RFC" / "change is cheapest when it's early" mindset). If so,

Please create a [RFC] nativefier-catalog issue where you describe your design & ideas, for discussion to happen between us.
I have a few ideas too, some are going in directions different from what you're doing, and there are constraints I'd like enforced for this to be maintainable. I'll prepare a md file with my design considerations, and feedback about what you already wrote. Then, I'll paste it as comment to your RFC.
Other people do the same (@TheCleric and other passersby interested in this: wanna participate?)
We discuss.

Adam Weeden · Answer 20 · Wed Mar 10 2021 21:38:22 GMT+0800 (China Standard Time)

Okay I have a fix that doesn't require a Nativefier code change:

Save the following as clear-sw-chache.js:

if ('serviceWorker' in navigator) {
    caches.keys().then(function (cacheNames) {
        cacheNames.forEach(function (cacheName) {
            caches.delete(cacheName);
        });
    });
}

Now run the following (adding any platform/arch commands desired):

nativefier --verbose https://web.whatsapp.com --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15" --inject clear-sw-cache.js

Seems to prevent the serviceworker from caching the browser. I do not use WhatsApp so I don't know if this impacts functionality, but it does fix the current issue.

Ronan Jouchet · Answer 21 · Wed Mar 10 2021 21:49:19 GMT+0800 (China Standard Time)

Seems to prevent the serviceworker from caching the browser. I do not use WhatsApp so I don't know if this impacts functionality, but it does fix the current issue.

@TheCleric if WhatsApp users confirm this fixes the browser issue and doesn't impair functionality, happy to merge this in a new flag --clear-serviceworkers on-first-page-load (leaving room for potential extension to other on-something events, e.g. on-app-exit, on-each-page-load, etc)

Itai Nelken · Answer 22 · Wed Mar 10 2021 21:49:23 GMT+0800 (China Standard Time)

Thanks a lot @TheCleric that works so far, I still have to test if all features I use work, but it seems they do.
also the injected file only runs when quiting the app, is that right? because I got the error that it needs a newer chrome version first time (didn't delete the Service Worker folder, but after quiting it and starting it again it worked).

I wish I didn't have to use whatsapp, but everyone else here uses it and they won't change to a different platform so...

Adam Weeden · Answer 23 · Wed Mar 10 2021 21:49:35 GMT+0800 (China Standard Time)

That being said, rather than adding a WhatsApp-specific flag, is there a generic flag we could add, that would deal with this WhatsApp trick, as well as maybe other sites? Would a new --clear-serviceworkers [on-app-exit|on-first-page-load|on-each-page-load] flag make sense?

@ronjouch A generic flag is definitely what I meant. I would never be in favor of an app specific flag. I was thinking something more along the lines of --clear-storage that works similarly to --clear-cache with the ability to specify which storage you would want to clear, Electron supports appcache, cookies, filesystem, indexdb, localstorage, shadercache, websql, serviceworkers, cachestorage, and we could also support all for a full storage delete.

So in this instance this issue would be solved with --clear-storage serviceworkers.

Though if my inject script above works we can table this unless we feel its truly needed.

Adam Weeden · Answer 24 · Wed Mar 10 2021 21:52:17 GMT+0800 (China Standard Time)

Thanks a lot @TheCleric that works so far, I still have to test if all features I use work, but it seems they do.

Awesome!

also the injected file only runs when quiting the app, is that right? because I got the error that it needs a newer chrome version first time (didn't delete the Service Worker folder, but after quiting it and starting it again it worked).

I think it runs on browser load, but it may be running after the service worker does its thing, so it may be a little late to the party. Anyone running the app fresh won't notice anything as it essentially will clean as it goes, it's only users like us who may have an existing serviceworker cache who would potentially have to load the app twice.

Ronan Jouchet · Answer 25 · Wed Mar 10 2021 22:00:37 GMT+0800 (China Standard Time)

@ronjouch A generic flag is definitely what I meant. I would never be in favor of an app specific flag. I was thinking something more along the lines of --clear-storage that works similarly to --clear-cache with the ability to specify which storage you would want to clear, Electron supports appcache, cookies, filesystem, indexdb, localstorage, shadercache, websql, serviceworkers, cachestorage, and we could also support all for a full storage delete.

@TheCleric 👍. To have everything centralized, we could get rid of mentions in docs & --help of the existing --clear-cache, and 1. move its documentation as part of the new --clear-storage, 2. keep "backwards-compat-honoring it", with a log.warn recommending to use the new thing. That way, we avoid adding yet another flag (we replace it), all the clearing things are in one place, old behavior is preserved, and people are pushed to move to the new thing.

Though if my inject script above works we can table this unless we feel its truly needed.

Agreed; no idea how common this kind of thing is.

also the injected file only runs when quiting the app, is that right?
[...]
I think it runs on browser load, but it may be running after the service worker does its thing, so it may be a little late to the party

More wood on this "on-event" consideration option I suggested above: if we introduce this option, we should probably default to clearing on-first-page-load, but we may want to let flag users specify otherwise. Use cases like the current WhatsApp thing might be happy with on-first-page-load, but other use cases might want on-app-exit or on-each-page-load, etc.

Adam Weeden · Answer 26 · Wed Mar 10 2021 22:35:01 GMT+0800 (China Standard Time)

@TheCleric 👍. To have everything centralized, we could get rid of mentions in docs & --help of the existing --clear-cache, and 1. move its documentation as part of the new --clear-storage, 2. keep "backwards-compat-honoring it", with a log.warn recommending to use the new thing. That way, we avoid adding yet another flag (we replace it), all the clearing things are in one place, old behavior is preserved, and people are pushed to move to the new thing.

Only thing to keep in mind there is that currently --clear-cache calls both session.clearStorageData() and session.clearCache(). So we'd need to know when/if we'd want to literally session.clearCache() in addition to session.clearStorageData(...). Perhaps supporting it via the user specifying appcache or just having our own value of cache that know to use clearCache instead of clearStorage.

More wood on this "on-event" consideration option I suggested above: if we introduce this option, we should probably default to clearing on-first-page-load, but we may want to let flag users specify otherwise. Use cases like the current WhatsApp thing might be happy with on-first-page-load, but other use cases might want on-app-exit or on-each-page-load, etc.

Maybe a combo like --clear-storage serviceworker=on-first-page-load (or swap them on-first-page-load=serviceworker) where providing no event has a sane default so you could say simply --clear-storage serviceworker, and support multiple passings like --inject so in theory it's expandable to something wild like --clear-storage serviceworker=on-first-page-load --clear-storage cookies=on-app-exit ...

Matthew Ruzzi · Answer 27 · Thu Mar 11 2021 09:19:07 GMT+0800 (China Standard Time)

@ronjouch @TheCleric I created [RFC] nativefier-catalog #1130

Adam Weeden · Answer 28 · Thu Apr 29 2021 23:59:57 GMT+0800 (China Standard Time)

@Itai-Nelken do you feel like this has been fixed sufficiently?

Itai Nelken · Answer 29 · Fri Apr 30 2021 00:21:28 GMT+0800 (China Standard Time)

@Itai-Nelken do you feel like this has been fixed sufficiently?

@TheCleric yes, but I think something about clearing the service worker's cache in websites that don't work should be added to the docs.

Itai Nelken · Answer 30 · Fri Apr 30 2021 00:22:24 GMT+0800 (China Standard Time)

Sorry, accidentally pressed the close button.

Adam Weeden · Answer 31 · Fri Apr 30 2021 00:47:13 GMT+0800 (China Standard Time)

@TheCleric yes, but I think something about clearing the service worker's cache in websites that don't work should be added to the docs.

@Itai-Nelken I'll see where we could add that at.

Adam Weeden · Answer 32 · Fri Apr 30 2021 13:25:49 GMT+0800 (China Standard Time)

@Itai-Nelken we've added a new troubleshooting section to our README that covers this and other common use cases. 😊

Eugenio Cilento · Answer 33 · Thu Aug 05 2021 22:21:42 GMT+0800 (China Standard Time)

I think this may be broken... i've been using the injected code per the readme as well as the "-u" options for some time and it stopped working today.

tried different user strings, even the keywords, etc. im on the latest nativefier on latest windows.

should I open a new issue??

Itai Nelken · Answer 34 · Thu Aug 05 2021 23:19:35 GMT+0800 (China Standard Time)

Same thing happened to me. After restarting the app a few times it started working again.

Eugenio Cilento · Answer 35 · Fri Aug 06 2021 22:21:15 GMT+0800 (China Standard Time)

Same thing happened to me. After restarting the app a few times it started working again.

Not doing it for me... tried restarting several times, deleted the app folder in appdata, that allows the app to reset and register with what's app qr code, but after that, if I close and reopen it pops up with the dreadful chrome v. 60 message. They are such a pain... I shouldn't use Whatsapp anyway, but I refuse to install their app. Unfortunately, I need it to keep in touch with family overseas...

Adam Weeden · Answer 36 · Sat Aug 07 2021 01:34:36 GMT+0800 (China Standard Time)

Same thing happened to me. After restarting the app a few times it started working again.

Not doing it for me... tried restarting several times, deleted the app folder in appdata, that allows the app to reset and register with what's app qr code, but after that, if I close and reopen it pops up with the dreadful chrome v. 60 message. They are such a pain... I shouldn't use Whatsapp anyway, but I refuse to install their app. Unfortunately, I need it to keep in touch with family overseas...

Is this also being built with the service worker fix outlined above?

Eugenio Cilento · Answer 37 · Sat Aug 07 2021 03:31:51 GMT+0800 (China Standard Time)

yeah... service worker fix injected as per the readme and the -u option set as well. tried all three and doesn't seem to work... it seems odd, but all of a sudden it stopped working.... rebuilt with latest nativefier, etc.. but no go 🤔

I used this code to make sure it was being called:

if ('serviceWorker' in navigator) {
    caches.keys().then(function (cacheNames) {
        cacheNames.forEach(function (cacheName) {
            caches.delete(cacheName);
			console.log("deleting " + cacheName);
        });
    });
}

This is the output in the console:

OS Name: Microsoft Windows 10 Home
OS Version: 10.0.19043 N/A Build 19043
Nativefier: 45.0.0 w/ Electron v13.1.7

Kieran Moore · Answer 38 · Mon Oct 25 2021 19:23:11 GMT+0800 (China Standard Time)

This also stopped working for me, but unregistering the service worker did work...

Built with:
nativefier https://web.whatsapp.com --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15" -n WhatsApp --inject unregister-worker.js --single-instance

unregister-worker.js:

navigator.serviceWorker.getRegistrations().then(
  function(registrations) {
    for(let registration of registrations) {
      registration.unregister();
    }
    if (registrations.length > 0) {
      location.reload();
    }
  }
);

Space Industries · Answer 39 · Wed Nov 24 2021 09:11:39 GMT+0800 (China Standard Time)

@kjmoore I can confirm, that works for me too. But the with the option --single-instance, the build does crash. So I removed that one.

Space Industries · Answer 40 · Wed Nov 24 2021 09:12:30 GMT+0800 (China Standard Time)

nativefier --verbose "https://web.whatsapp.com/" --user-agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15" --name "WhatsApp" --icon "whatsapp.icns" --inject unregister-worker.js