Extension can only delete one page of emails at a time #81
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
First off, thanks for the extension and open sourcing things. I saw you're video and it looks nice. I've basically abandoned an email because I get too many messages there.
Specs:
OS: Linux Mint 22.2
Browser: Chromium 141.0.7390.107
Extension Version: 2.1.0
What's Happening
If I repeat this process many times manually, the extension will stop working altogether. I have to close my Gmail tab and bring it back.
I'm not sure what logs you'd want to debug but obviously willing to send anything over for triage.
Same:

same. just 75 emails from 10 senders, click delete and get that error. first time user.
same, chromium ubuntu. works when <100 emails from a sender
A quick work around until a fix is found, is to use the delete button in the extension once. If it fails, then use the search query that it created to select and delete emails for each page. It is still time consuming, but the extension makes the query creation way easier.
Yeah @jereditt I noticed that when you do that, if you go too fast, before gmail loads the next 50, it will error out. I wonder if that's what's happening on this issue as well. The extension may be trying to delete the next page or select a piece of the DOM before it is marked as ready. Might be good to add in some async callbacks to ensure the DOM is ready for the next delete operation.
I have also been running into the deletion failures mentioned above (definitely seems like it could be a timing/race condition when paging through the email chunks). I wanted to propose an alternative deletion flow that might avoid the issue, if it hasn't been tried already.
Idea: Why not use Gmail's built in "Select all conversations that match this search" banner and perform a single delete action? From what I can tell, the delete button's intention is to delete all conversations matching the query anyway. Using the banner would mean the extension doesn’t need to step through each page of 50 emails and wait for the DOM to update, which should avoid most of the async timing problems.
We could load the search URL that the extension already creates, select the checkbox, and wait for the yellow banner that deletes all and click its link.
I definitely think this should include an extra confirmation of some sort since it can delete thousands of emails at once, but that may help in terms of reliability for the heavier cleanup tasks.
If this seems useful I'd be happy to help work on it, I do really like the extension and think it's nice to get a clear view on what is really cluttering my inbox after a number of years of ignorance!
@ZingBing This sounds like a solid solution if the "Select all conversations that match this search" is something that always shows up. From my preliminary testing in my own Gmail inbox, it only appears when selecting all without a search.
So, for example, without anything in the search bar it appears:
But as soon as I put something in the search bar and carry out the same steps, it no longer appears:
Am I missing something, or is this one of those Gmail UI things that somehow varies between accounts?
@anna-st-40 It took me a while to realize, but I believe it will consistently show up as long as the sorting selector on the side to the right is set to
Most recentas opposed toMost relevant. I actually found this out when I tried using the extension originally and the delete feature wasn't working, and thought there should be some easy builtin way to delete all conversations. However, the option wasn't showing up for me either... only after some digging did I discover that this was the reason.Most recent selected

Most relevant selected

As you can see, with
Most recentselected I have the option to select all conversations, even though there is a filter on the search.So I guess my idea would also include ensuring that
Most recentis selected when doing a mass delete.@ZingBing Got it, that makes sense. If you’re up for it, go ahead and try implementing it. I’d be happy to review and test.