I think I know what's happening here. The loading template (which is displayed as part of GfmAutocomplete.setup) is being injected 3x because setup is being run for each editable note on the page. This happens because setup initializes the autocomplete ui before checking to see if data is already being loaded. So I think it's possible that the number of duplicated loading messages could be higher than three in certain conditions. It probably varies with connection speed, the number of editable notes on a page, and maybe, the device's CPU/memory constraints.
More specifically, the request for autocomplete resources probably isn't returning quickly enough to change the dataLoadingflag to false before setup is run again. This was recently fixed, to ensure GfmAutoComplete is initialized only once per page (https://gitlab.com/gitlab-org/gitlab-ce/commit/4e34a495875aae0a9021da69330c292fd95a6955). I don't know if it has made it into a release yet, but I'm guessing it solves the problem here.
@blackst0ne Could you try reproducing it on a fresh copy of master and then try reproducing it somewhere that doesn't have 4e34a495 yet? If I'm right, you shouldn't be able to on master, but should be able to elsewhere.
Could you try reproducing it on a fresh copy of master and then try reproducing it somewhere that doesn't have 4e34a495 yet? If I'm right, you shouldn't be able to on master, but should be able to elsewhere.
The problem is, I don't still know hot to reproduce this bug manually. Network throttling doesn't help.
So, I can try to do something in fresh master, but I do not know what to do here.
I've definitely seen this bug before, but I couldn't reproduce it when I tried to for this issue. I could only guess by looking at the code.
Maybe we could leave the issue open for a bit, assume it will be fixed in the next release, and then see if it surfaces again? That doesn't seem like a great solution, but I'm not sure what more we can do at this point.
Since working on this source code in !6856 (merged), this issue seems even weirder. This Loading... text is passed to at as the initial data object, for example, $.atwho({ someConfigKeys: someConfigValues, data: [ 'loading' ] });(which then triggers it to select the loading template).
I think what could be happening instead is that the atwho is being initialised 3 separate times and the 3 separate Loading... elements are just being placed in the same container so it looks like the 3 Loading... belong to one instance, when really its 3.
If this is the case, and even if it isn't, !6856 (merged) will likely fix this issue as it limits the instantiation of atwho to focus and blur of the inputs. So unless these events are triggered multiple times, it wont instantiate multiple times.
The trouble is, I don't want to add Closes #22802 without being able to reproduce this and confirm. 😢