Issue page: "Authors" drop-down loads ALL authors and their avatars

[drsybren]

Description

The "Authors" drop-down on the repo issues page (so on the /{owner}/{repo}/issues URL) has HTML elements for all authors, and will load all of their avatars. This does not use a virtual DOM, this does not wait until the drop-down is actually opened, this happens immediately on page load.

I'm one of the Blender developers tasked with porting our data from https://developer.blender.org/ to Gitea. My local Gitea database holds 33164 users, 4 organizations, 44 repositories, 93035 issues, 731996 comments, and 749 labels. The list of "issue authors" in the Blender repository has 24919 items.

The culprit is templates/repo/issue/list.tmpl, which has this snippet in the "Authors" drop-down code:

{{range .Posters}}
	<a class="{{if eq $.PosterID .ID}}active selected{{end}} item" href="{{$.Link}}?type={{$.ViewType}}&sort={{$.SortType}}&state={{$.State}}&labels={{$.SelectLabels}}&milestone={{$.MilestoneID}}&project={{$.ProjectID}}&assignee={{$.AssigneeID}}&poster={{.ID}}">
		{{avatar .}} {{.GetDisplayName}}
	</a>
{{end}}

That .Posters list is thus 24919 items long, and it generates an <a> tag with an <img> tag for every single one of them.

You can see this on any issues page, for example https://try.gitea.io/orgddfafgsjj/rep/pulls

Screenshots

Gitea Version

29b78bc

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

No response

Browser Version

Firefox 109.0

[silverwind]

I think this is a limitation of Fomantic UI Dropdown. What should probably be done is to create these dropdowns with tippy.js and find a way to lazy-load and/or paginate the user dropdowns.

[lunny]

I think this is a limitation of Fomantic UI Dropdown. What should probably be done is to create these dropdowns with tippy.js and find a way to lazy-load and/or paginate the user dropdowns.

I don't think paginate is necessary, maybe a search box with limited results i.e. 10 or 20 is better.

[silverwind]

Paginate with a infinite on-scroll loader would be ideal I guess. Problem with limited filter is that if you search common terms, some valuable results may become hidden from view.

[lunny]

Paginate with a infinite on-scroll loader would be ideal I guess. Problem with limited filter is that if you search common terms, some valuable results may become hidden from view.

I know it can be implemented. But it's really unnecessary to do that. If we want to at somebody, we will remember his name or copy his name. Searching a in that box is meaningless. And take a look at Github, it will list about 20 or 30 authors and there is also no pagination.

[drsybren]

Please keep in mind that we have some short names as well. Searching for “Ton” should have Ton at the top. We’ve had this as an issue with other systems, just want to avoid seeing the same issue here.

[silverwind]

Yeah that is what I was getting at. If you only know "John" first name and there are 50 Johns, you have a problem with a limited display number.