Multi-task interface can take a while to save the result of many tasks

[ygra]

Describe the bug
Using the Multi-task feature (awesome for certain tasks, by the way), when editing hundreds of tasks saving the result (Fixed, Already fixed, etc.) can take a while. While in itself that can be expected, the UI remains responsive during that time, giving no indication that work is still happening in the background and potentially leading to further interaction that might compromise the background operation.

Expected behavior
Some sort of indicator about ongoing background work would be nice, especially because the UI switches to the next task only after background work is complete and the UI can be used during that time.

This was noticed in challenge 44817 where there are some places that have hundreds, if not thousands of tasks already fixed and this allows really efficient processing here. I guess for more edit-heavy tasks with lots of work to be done you wouldn't often edit hundreds of items at the same time. For 149 tasks saving the result took 19 seconds for me.

[mvexel]

A couple of comments here @ygra and thanks for raising this issue.

1. The next version of MapRoulette (to be release in the next month) will see significant improvements in the multi-task workflow including performance improvements
2. I still think the best way to deal with 'already fixed' tasks, especially large amounts, is to let the challenge owner know so they can update the challenge.
3. Enabling completion actions on 100s / 1000s of tasks at a time would open the door to abuse or at least unintentional destructive actions on large numbers of tasks, so I want to be careful enabling that.

Did you contact the challenge owner about the large number of already fixed tasks?

[ygra]

Did you contact the challenge owner about the large number of already fixed tasks?

Yes, I did. They rectified that quickly. However, that particular challenge was also very amenable to fixing hundreds of tasks at once, especially when large numbers of trees were mapped in a single location. So even for tasks that aren't already solved it's helpful.

With enough tasks solved at once you also invariably get an error that the next task cannot be locked, which may also be due to the long delay between clicking "Submit" and the next task loading.

That being said, I'm not sure how often this is actually a problem. Many challenges are more complex to solve or require drawing/changing geometry where it's typically unfeasible to handle hundreds of tasks at once. So this might be a special case for challenges that

1. Gather lots of tasks in close proximity
2. Require only tag updates
3. ... with many tasks sharing basically the same or similar updates

I don't see the number of tasks to multi-task exceeding a few dozen at most for most other challenges. At least not if you want to complete all tasks in a reasonable time and want to keep the changeset bounds somewhat sane.

[mvexel]

Thanks @ygra for the additional comment / info.

I am curious to see what you think after we deploy the new version. I hope it is an improvement for your work.
Also if the tasks just involve tag changes, you may consider a tag fix challenge.

I will leave this ticket open in case you want to discuss further, but feel free to close it at any time.