This is a minor gripe, but it has been happening for a long time. Usually, after uploading a batch of observations, I scroll through them to add annotations and do other cleanup. Starting from the last one posted, I use the green “previous” arrow/button (upper right corner of the web interface) to scroll back through the observations. Pretty frequently when I do this (maybe particularly after adding an annotation? haven’t figured out the exact pattern) the previous observation flashes up, but then it goes back to the one I was just on, although the URL doesn’t change. I then have to refresh in order to make the observation load correctly. Sorry if I haven’t explained it clearly - it’s a little confusing. Has anyone else experienced this? I think it has happened to me in both Firefox & Chrome.
Yes, I have seen this too, and in my experience it happens when there is a system delay in processing a change to the record last edited. It seems that the last action after the change is successfully processed is to refresh the observation detail window for that record. If you have already hit the back arrow, the delayed refresh seems to force the previous window to become active again. I have learned to wait for signs that the previous edit is finished processing before arrowing to the next (or previous) observation.
That said, when I am moving faster that the system is, it would be nice if it would not try to refresh previous windows if I have already moved on to a different record, and instead just silently finishing processing those delayed edits.
It seems to be even worse if, in the process of refreshing a previous window, re-displaying the map is running extra slowly, as it often does. The back arrow stays grayed out until the map finishes loading. Would be better if the navigation arrows were always immediately available, and any unfinished window updates just discarded. (Of course, edits specifically saved by the user first should still be completed in the back end.)
Makes sense that it would be a latency issue. I agree that repressing the refresh & finishing up behind the scenes would be preferable behavior, but might be more of a pain to implement than is warranted. I will try to be more patient, and if at some point annotations are available in the upload interface I might not need to do this so much (although looks like @tiwane has a clever workaround).