https://gitlab.com/gitlab-org/gitlab-ee/issues/3889 brings the comment thread to epics. Likely #3889 (closed) will be done before we solve autocomplete. So that means the comment thread when it's introduced also will not have autocomplete. When #4084 (closed) is designed and released, it should apply for both epic description and epic comments.
The code is currently defined to turn everything on or off. With some small refactoring, we can configure specific autocompletes but this may lead to weird UX (Users will not know why certain autocomplete works everywhere else but in epics).
I think we would both agree that we should disable issue and merge request autocomplete because the UX is not defined yet. The question is whether it would be strange to disable a few autocomplete dropdowns. Would it be a better UX experience to have it all disabled and perhaps have some kind of note saying that autocomplete is not currently supported yet?
From a code perspective, it looks like we have to set gl.GfmAutoComplete.dataSources in JavaScript to map the API URL. It seems like we load that info by default on pages that have gfm-form as seen in
= render "layouts/init_auto_complete" if @gfm_form
...disable just issues and merge request autocomplete, or just disable all of autocomplete altogether for epics.
Jumping in as @pedroms is off today @victorwu. I would rather disable autocomplete altogether for Epics until proper UX work is done. I believe it would be confusing/frustrating for users if it sometimes worked and sometimes did not.
Thanks @sarrahvesselov. I updated the description to say autocomplete is off for everything in description and comments for epics. Please see to make sure it's what you were thinking about. Thanks!
All of these should not be possible as autocomplete (with the dropdown) in the epic description and the epic comment thread in the future.
Clarification, we never intend to add autocomplete @victorwu? I assumed this was a temporary state because it does not work consistently in all areas of Epics.