Closed IsaacHatton closed 10 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?
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.
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
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?
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 😆
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?
Yes, you're right!!
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...
Yes, that's absolutely fine, go ahead
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
View Once more info
(this example uses a photo, but it works for videos and audio messages too) When clicked: I am unsure if that is worded well, can you suggest what it should be changed to?
View once audio messages
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.