Failed to complete removal.

[narjekdjcusbe]

Shoot the Messenger 5.0.1 Chrome 96.0.4664.110 (Official Build) (64-bit) Language: English (UK)

Running on a thread, search works and it moves up the conversation using search to keep its place. After a while, before it removes all the messages, it will freeze and not resume. Often it will refresh the page after it freezes which clears the console logs, but I've attached logs I have managed to capture and will add any more as updates if I capture more.

www.messenger.com-1641320560628.log

shoot-the-messenger.log

This is the log that I saved while in progress almost immediately before a hang - it was running on a thread that had already been partially removed and previously failed. www.messenger.com-1641381166612.log

This I saved immediately after the hang - it didn't refresh but seemed to have cleared some of the console www.messenger.com-1641381166612.log

It's also logged errors into the chrome extension - so I've attached them too - looking through them I'm not sure if these are true errors or your notes. Uncaught-in-promise-TypeError-Cannot-read-properties-of-undefined-reading-parentElement.txt Uncaught-in-promise-TypeError-Cannot-read-properties-of-undefined-reading-parentElement-2.txt

Edit: Finally caught it in an error. Closing the error and restarting it results in the same error www.messenger.com-1641398639305.log .

[bluevex]

I encounter this as well, the program stops after 20-30 minutes or so. Clicking "remove messages" again makes it continue.

[narjekdjcusbe]

I think I may have worked out part of what's going on. It seems to fail when the message fragment it searches for is generic enough to appear multiple times in the conversation (e.g. "Hi, how are you today).

Sometimes this seems to cause it to crash, sometimes it just carries on, but picks up again but from the most recent search. If this recent search is more recent than it had previously run through, it starts running through messages that have already been deleted. I'm unsure on the conditions that dictate crash vs continue from earlier.

[theahura]

Whoa totally missed this issue. Sorry about that.

Thank you @narjekdjcusbe for doing the further analysis. The message fragment search being too generic was definitely something I thought might happen, but I thought I set the parameters for search selection to be...well, selective enough that this wouldn't be a problem.

Are you running the chrome version or are you running the github version? If the latter, I'd be curious about whether you could change some of the parameters in the code to test if that fixes the issue. The relevant parameters are here: https://github.com/theahura/shoot-the-messenger/blob/main/main.js#L303

Copied below:

  // Find a message that wasnt the previous message with at least five words
  // that have more than 4 characters.
  const filtered = availableMessages.filter((t) => {
    return (
      t !== prevMessage &&
      t.split(/\s+/).filter((w) => w.length > 3).length > 4
    );
  });

You could replace the 3 with a larger number to require more than 4 characters; you could replace the 4 with a larger number to require more than 5 words.

This should be pretty rare because you'd have to get an exact match on the search :thinking: I'd be curious to know which 5+ word phrase you're using more than once in a chat

[theahura]

Going through the logs you posted, some of the errors are 'expected', e.g.

main.js:117 TypeError: Cannot read properties of null (reading 'getAttribute')
    at prepareDOMForRemoval (main.js:114)
    at async unsendAllVisibleMessages (main.js:132)
    at async runner (main.js:244)
    at async removeHandler (main.js:330)

will not impact anything.

But this error:

main.js:282 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'parentElement')
    at runSearch (main.js:282)
    at async removeHandler (main.js:324)

is new and bad. I'll have to look into that one...

[theahura]

Just pushed version 5.0.2, see if this fixes any issues?

[narjekdjcusbe]

Running 5.02 now. Definitely feels more stable - haven't seen it crash on a small message that has multiple hits, but still hitting a couple of errors.

Firstly: Extension will read the contents of link previews (e.g. for youtube) as a "message" to be searched for, but Messenger does not allow for searching in link previews, so it will fail with 0 results found. Not sure how easy a fix that is, but it's definitely what's happening so haven't included logs.

Secondly: still catching the odd error. Key line appears to be www.messenger.com/:1 Unchecked runtime.lastError: The message port closed before a response was received. but haven't quite established a pattern of what it could mean yet.

www.messenger.com-1642607074359.log

[theahura]

I have no idea how it could have that first error. Before selecting a search text it explicitly tries to search for that text, and if it doesn't succeed moves on to try something else. Are you sure that's what youre seeing?

No idea what the second one is either.

[narjekdjcusbe]

Sorry for the delay. Generally it runs fairly well, it just requires a bit of handholding and manually finding the place and restarting here and there.

Have caught a few errors, but nothing major I don't think.

• It's fairly common that messages get skipped. Sometimes it's just one or two, but it will often run for 5+ minutes without anything actually being removed. It runs completely normally, no errors, just messages don't get removed when clicked. After a while they will start getting removed again. I think this is a form of undocumented soft rate limiting on the facebook side rather than a STM bug.

• I'm certain about the youtube video, but it's only happened twice - it doesn't really seem to be a big deal.

• The search still is buggy, but it seems to lie mainly with Faceboook's cr*ppy search system. Occasionally, certain long strings of text will "match" 3-4 messages despite not matching at all. Usually it finds the right one anyway, but sometimes it doesn't and gets stuck. No idea at all what makes the difference. Rarely, it stops with the below error. I suspect it's my meddling hand holding that's introduced it, honestly:

_``` Uncaught (in promise) TypeError: Assignment to constant variable. at runSearch (main.js:280:31) at async removeHandler (main.js:333:11)

[theahura]

Latest version on github should address the 'assignment to constant variable' issue. I'm not sure why that was being triggered at all, but maybe its like a weird chrome browser thing. In any case, give that a shot and see if it solves problems.