I always thought it was a bug that the Identify Modal runs through data from previous observations when you click on Suggestions. Is that how it’s intended to work? I find that it really slows down my workflow, and that it often gets stuck such that I have to leave the Suggestions tab and come back (sometimes more than once) to get it to refresh to the data from the current observation.
1 Like
Happens to me as well. In the unlikely event it’s intentional, I find it highly irritating.
I wonder if it’s only an issue for users with slow internet loading times?
I’ve got quite fast internet at my place, my guess is it’s on the iNat and/or browser side, probably the former, especially if the site is busy. There is a lot going on on the Identify page, it’s pretty resource hungry and makes a lot of API calls. It’s certainly not intentional.
So would this be appropriate to report as a bug? I know I would very much appreciate a fix.
1 Like
For sure, but I can’t estimate when a fix might be, unfortunately.
1 Like
Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.
Platform (Android, iOS, Website): Website
App version number, if a mobile app issue (shown under Settings or About):
Browser, if a website issue (Firefox, Chrome, etc) : Firefox on Mac
URLs (aka web addresses) of any relevant observations or pages:
Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
Sometimes when stepping through observations to identify, the country shown by the map is incorrect. I think when this happens, it is showing the country from the previous observation.
This isn’t the first time this bug has been reported, and it was fixed before. Rather than rely on the asynchronous javascript, can we blank that field when switching observations, so if we do not get the updated info, we show nothing rather than incorrect data?
2 Likes
does this bug report really need to exist, given that you also logged this feature request (https://forum.inaturalist.org/t/update-the-website-u-i-to-better-handle-slow-server-responses/23399)?
These are different. This isn’t the system just being slow updating this. Sometimes it never updates. This one sat on my screen for more than a minute before I took the screen shot.
hmmm… i’m not on Mac, but when i switch between observations in either Firefox or Chrome on Windows, i do see the country switching to “somewhere on Earth” before being replaced by the country name as each observation loads. as far as i can tell, if there is no country returned, the country remains “somewhere on Earth”. does the “somewhere on Earth” not happen on Mac, or does it switch to “somewhere on Earth” before being replaced by an incorrect country?
just for reference, here’s an Identify query that pulls back observations from on/near land (which would have a country) and in the ocean (which would have no country and should keep “somewhere on Earth”): https://www.inaturalist.org/observations/identify?reviewed=any&nelat=-20.9398005481376&nelng=-81.37367477465583&subview=map&swlat=-41.425354720906014&swlng=-141.38539245177222&taxon_id=47178
i also specifically went into my browser’s network monitor and blocked the API request URL associated with a particular observation, and that caused the API request to fail. in that situation, the “somewhere on Earth” also remained, as opposed to switching to the previous observation’s country. (so i couldn’t reproduce the problem that way either… so maybe this is just a Mac thing.)
I can reproduce in Chrome on Windows, but only if I skip through multiple observations quickly. This one showed somewhere on Earth briefly, then Czechia, then Russia. The actual Russian observation was the one before it.
- Open Identify Modal
- Hit right arrow 3 times
- It will show “somewhere on Earth” and then maybe get the correct country, but often it will go through multiple countries and finish on the wrong one
1 Like
ok. i can see the cycling through countries if i throttle my connection in the network monitor. if i quickly cycle through A (country X), B (country Y), and C (no country), and i’ve blocked the request URL for C, then i do see C ends up country Y.
so then the issue isn’t that it’s not “blanking” the field (using “somewhere on Earth”), but it’s potentially getting data from multiple observations, and it should either cancel the requests associated with the other observations, or it should use only the results returned from the current observation.
For me, it’s also showing different locality levels (sometimes the county, sometimes the state, sometimes the country) and sometimes showing the locality as being the same as the previous locality. I reported that here before I saw this:
https://forum.inaturalist.org/t/in-identify-modal-place-suggestion-dropbox-sometimes-county-sometimes-country-sometimes-wrong/24644
I’ve run into this problem pretty frequently too. The Identify tools could really use some upgrades.
1 Like
Yes, I’ve noticed this too. It seems that Google can’t keep up with iNat at times.
(I merged a few reports)
To me, it looks more like a “race condition”. The web site is “multi-threaded”. A request gets sent to the server, and while the browser is waiting for the reply, you’re clicking different things and thus send further requests, and somewhen the replies come back to your browser, but not in the order you would need them.
From a software developer’s point of view, quite the naughtiest thing you could have to try to fix.
Because everytime you try to repeat the issue, a little different timig is required, and reproduction fails… And of course, it does also depend on the JavaScript implementation of your browser. Infinite number of combinations possible.
2 Likes
yup.
it’s possible to reproduce the issue fairly reliably. for example:
Has anyone encountered this since last week’s downtime? I encountered it pretty often before that but I haven’t seen it happen since then and I’ve been going through observations pretty quickly in the past few days.
That sounds like a different issue.
Well I’m pretty sure the work we did during the last downtime fixed this, at least for now, so I’m going to close the report.