Add status downloading

[IsaacHatton]

In reference to https://github.com/tomer8007/whatsapp-web-incognito/issues/68

I'm new to this codebase, apologies if I have done anything in non-standard ways (e.g. hardcoding the svg in code or variable names).

Also, when a new status first loads, the src value is something like this, which this code will fail to download, and the icon won't appear: However, after they have been loaded once they use a string starting with "blob:web.whatsapp.com" as src which can be downloaded which will be detected by this code.

Despite these flaws, it is still useful as you just have to reopen the status (I can add a warning for this if you would like this) and it can be saved.

[tomer8007]

Hello, thanks for the pull request. I would suggest:

• Instead of pulling for DOM changes every 400 ms, you can use MutationObserver like this: https://github.com/tomer8007/whatsapp-web-incognito/blob/802aa18437a323d71302a4e6bf8f3f530949fa30/core/ui.js#L38
• Instead of hard-coding the SVG file, you can look on how I did this here: https://github.com/tomer8007/whatsapp-web-incognito/blob/802aa18437a323d71302a4e6bf8f3f530949fa30/core/ui.js#L123

[IsaacHatton]

I have made those changes, is that MutationObserver ok or do I need to find a way to make it more finely scoped?

[tomer8007]

Please try to make the MutationObserver use its parameters in a more dedicated way, Also can you attach a screenshot of the download button in a status?

[IsaacHatton]

I have changed the mutation observer, so that the main one that will be running the most only checks for changes involving a status.

[tomer8007]

But you are now creating a new MutationObserver inside the previous MutationObserver callback. You should filter by the elements you want to observe like I did. Look at the docs.

[IsaacHatton]

Apologies, I am new to MutationObservers, is this the way that it should be structured?

I tried to copy and modify the code in the section you mentioned.

[tomer8007]

Yes, this is better. Does the button addition when viewing a status work correctly? Can you download both photos and videos correctly?

[tomer8007]

Maybe you can create a "re-open this status to download" text when you see a weird src value (not a big modal warning, just instead of the button)

[tomer8007]

Do you want to add the "re-open this status to download"?

[IsaacHatton]

Sorry yes I think it's a good idea, just haven't had time to work out how to implement.

[tomer8007]

OK

[IsaacHatton]

To be able to get the re-open prompt to work I had to make some changes, also the old setup was behaving wierdly, I think this should reduce wierd bugs that appear, please check if this is suitable.

[tomer8007]

P.S Sorry for the delay, I missed your comment

[tomer8007]

Also, how stable is your solution right now? Are there any bugs? Can you post a photo of how the re-open prompt looks like?

[IsaacHatton]

This is the re-open prompt in the current state:

I haven't noticed any bugs so far, I think it's quite stable.

[tomer8007]

If you know you will always need to re-open the status, maybe change the text to "Please re-open the status to download"? Also can you show the prompt in the fuller context (next to the status)?

[IsaacHatton]

![Uploading Screenshot_20231229_154506_Chrome.jpg …]()

[IsaacHatton]

[tomer8007]

OK, and how does the new text look like?

[IsaacHatton]

[tomer8007]

OK, let me know when you think the PR is ready

[IsaacHatton]

The lines highlighted in pink can fail if it is not a status, and the one in orange will fail if the previous pink one fails.

I can't think of a way to put this in a try catch efficiently.

[IsaacHatton]

I have just tested it again, and I believe it is functioning as expected.

[tomer8007]

I can't think of a way to put this in a try catch efficiently.

OK, well, nevermind. At worst we'll just have a javascript error thrown. We just need to make sure the download button won't appear.

[IsaacHatton]

It won't appear as if there's an issue it will always return false and the only place the function is used is here where false will make it stop:

[tomer8007]

But we don't want the error to be silently ignored. So either remove the try/catch block, or throw the original exception.

[IsaacHatton]

Found a solution to the error messages, I am using optional chaining now

[tomer8007]

Does it still work correctly?

[IsaacHatton]

It is working with the normal (non re-open required) status downloads, give me a sec to test with a new one to trigger that condition.

[IsaacHatton]

It is working with re-open statuses as well

[tomer8007]

Good. Anything else you want to change before I merge?

[IsaacHatton]

I was just wondering, in terms of maintainability etc what kind of indentation/comments/etc are needed, is everything fine as I can see it doesn't match some other parts of the codebase?

[tomer8007]

Yeah, I would like it if you could match the indentation to the rest of the code

[IsaacHatton]

Ok, will do.

[IsaacHatton]

I think that matches the code style of the other files

[tomer8007]

Did you check that everything is still working?

[IsaacHatton]

Yes, it is all still fully functional, the only errors in console have been there the entire time and they are in files and functions completely unrelated to this pull request.

[IsaacHatton]

[tomer8007]

Yes, these errors are really normal. If you find other issues with the extension such as crashes or messages not being sent, I would like to see issues for these. Do you think the PR is ready now?

[IsaacHatton]

Yes I think it is ready, thank you for all of your help.