Closed canscaw28 closed 1 year ago
Interesting...the extension tries to get around what you're experiencing by saving a message, refreshing the page, and then using the search feature to go back to the saved message. That feature could be broken, though I think based on #80 it should work.
Maybe the total number of times it tries to scroll up before a refresh needs to be brought down to work better on different machines. Try setting RUNNER_COUNT from 10 to 5?
Re: using endpoints, I had trouble working around facebooks API and thought it was much more likely to be caught as spam, resulting in actually getting people's accounts banned
Oh interesting, one thing I notice when running the script was that the DOM preserved all of the list elements. So if there was intended to be a workaround by refreshing the page and using search to jump to the desired location, I'm not sure if it's working? 🤔
Re endpoints: yeah I think your reasoning makes sense. I was digging around as well and it wasn't immediately obvious to me how to interact with their API, but was wondering if you had any initial luck 😅
If a refresh isn't clearing out the memory, I'm not sure what an alternative would be :thinking: it shouldnt be preserving the DOM on a refresh
As stated the long chains shouldn't be a factor. After a short number of messages are loaded into memory, It takes a partner chat message that's unique, refreshes the page and searches for that message again.
At no point should you be manually scrolling.
If a refresh isn't clearing out the memory, I'm not sure what an alternative would be 🤔 it shouldnt be preserving the DOM on a refresh
It does clear on my end, Went from 120 partner messages in memory to 7 with refresh.
Hmm I'm not sure then? One thing I noticed is that search isn't working for one of my chats. Messages that haven't been unsent, but are X years old are not showing up after explicitly searching for them. The only solution for me is to manually scroll 🤔. This also might explain why I haven't been seeing the refresh + search behavior? But I haven't extensively looked into it.
Edit: seems to be unique to just one chat.
Maybe try my last pull request that adds regex filtering.
Giving it a try - thx! Re manual scrolling: doesn't seem like there is a way to avoid this. If a decent chunk of the latest messages have already been "unsent," what happens is that the script scrolls up a few times and then ultimately stops.. producing the error in https://github.com/theahura/shoot-the-messenger/issues/80. My work around is to run the script again or manually scroll
I did extensive testing with years old conversations with the version that's live and it never failed. We need better troubleshooting maybe.
I did extensive testing with years old conversations with the version that's live and it never failed. We need better troubleshooting maybe.
Hmm, I can't say that's the experience I've been having. My current workaround involves setting the RUNNER_COUNT=1000;
. This seems to ensure that the script keeps scrolling, requiring minimum overhead. However, every now and then the script fails, or worse yet, the page crashes with an "Aw, Snap!" message. This is not terrible, since at least I can keep the script running in the background and occasionally re-trigger it again when needed. However, I'm definitely not getting the smooth run you seem to be getting :(
Setting the runner count that high will definitely result in page memory crashes. Really it seems the weird thing is the search feature not working... But if you've observed that search is broken even manually, ie outside of the extension, there's nothing the extension can do -- after all, it is just mimicking human button presses
re crashes: think this could be an easy fix -> 1) keep scrolling until you find the first message that can be deleted. then 2) resort to normal behavior with a normal runner count (e.g. 10).
re search: yeah no idea here. Manual search 100% doesn't work on this one chat. Going to write this off as a unique situation since there's no evidence that anyone else is experiencing this :/
For conversations where the number of messages far exceeds >1k, the behavior of the script starts to slow down. This is probably due to poor state management on FB messenger's part, but I haven't confirmed the exact cause. I'm also experiencing the issues mentioned here: https://github.com/theahura/shoot-the-messenger/issues/80. This ultimately forces me to scroll up again, which can take >10mins.
Love the tool, but it's not clear to me that i'll be able to use this for long message chains.
Have you considered an other approach? Instead of mimicking browser interactions, maybe there are specific endpoints we can interact with (e.g. something like an
unsend_response
request, orget_next_N_messages
etc.).