tomer8007 / whatsapp-web-incognito

A Chrome extension that disables read receipts and presence updates on WhatsApp Web
MIT License
312 stars 74 forks source link

View Once more info, support view once audio messages, and fix race condition that results in not showing view once messages if the chat is open. #154

Closed IsaacHatton closed 5 months ago

IsaacHatton commented 5 months ago

View Once more info

image (this example uses a photo, but it works for videos and audio messages too) When clicked: image I am unsure if that is worded well, can you suggest what it should be changed to?

View once audio messages

image As this uses the default audio element, it can be downloaded or have the playback speed changed in my browser (MS Edge 120.0.2210.91)

Race condition fix

I don't know much about how JS handles promises, async etc in the event loop, but my fix (interception.js 466 and 488) seems to ensure that WhatsApp doesn't try to render the view once until it has been written to the IndexedDB.

I can tell this fix is a bad idea, but I don't know of any other way of doing this, so please can you help me modify this to make it work.

There's a small issue wherein if the view once is sent while the webapp is closed, and then the user opens it and within 5 seconds of it opening views the chat, it will not change anything and the default UI (non-extension) will show. However, this issue is also present in the deleted messages feature, where messages don't get highlighted in this case.

tomer8007 commented 5 months ago

Your sweetalert message looks fine to me. Why do we want to block the write to the DB before rendering of the message?

IsaacHatton commented 5 months ago

When the message renders, this is detected by the UI script, which will check the DB to see if there is a message. As this script only runs once and won't update if there's any kind of change, this means that the write to the DB must complete first.

Without the async/await addition, if a message arrives while the chat is open, it won't show it until the element is removed and readded to the DOM (switching chats etc)

I don't really understand the event loop, so I might be misunderstanding this.

neo2701 commented 5 months ago
window.webpackChunkwhatsapp_web_client.push([
    [Math.random()], {}, e => {
        e(729804).default.Msg.on("add", msg => {
            msg.__x_isViewOnce = false;
        });
    }
]);

that code seems to just mark the Msg as normal message, and enable the function to zoom and others

IsaacHatton commented 5 months ago
window.webpackChunkwhatsapp_web_client.push([
  [Math.random()], {}, e => {
        e(729804).default.Msg.on("add", msg => {
            msg.__x_isViewOnce = false;
        });
  }
]);

that code seems to just mark the Msg as normal message, and enable the function to zoom and others

@neo2701 This code looks much cleaner and better implemented than mine.

Do you know if this solution will be impacted by the expiration of messages, the way I read the article is that the 14 days is a server side countdown and then it deletes the message from the cloud bucket they use? https://faq.whatsapp.com/1077018839582332 With my original solution, the messages were stored in a seperate IndexedDB.

Also, how do you think would be the best way to detect and tell the user this is a view once and to allow them to click "Learn more" in both chat and fullscreen view?

neo2701 commented 5 months ago

About the expiration, i agree with your current solution by storing on IndexedDB. And to tell the user you can use your current UI implementation just by appending the element for view once icon and learn more on left side before received message timestamp. I'm not good at UI/UX though 😆

IsaacHatton commented 5 months ago

Ohh, I think I understand, your suggestion is that I use your method and then make UI changes to make it clear that it's a view once, but keep mine in as a fallback for when it expires?

neo2701 commented 5 months ago

Yes, you're right!!

neo2701 commented 5 months ago

Is it okay to make new pull request from your fork that fixes the view once media caption not restored? Cause i kinda fixed it...

IsaacHatton commented 5 months ago

Yes, that's absolutely fine, go ahead

neo2701 commented 5 months ago

Please kindly check my code, Thanks! I noticed that when you mentioned a person or if the caption contain links it still didn't formatted correctly in the chat window