Change branches loses title, description, labels, milestone from new merge request form

Summary

Clicking ‘Change branches’ and changing target branch for a merge request loses anything you’ve typed into the title/description/milestones/labels fields of the new merge request form.

Since the ‘Target branch’ entry is quite far down the form, it’s likely that people will fill all those fields in first, before remembering that they need to change the target of their branch. This often happens (for me) with cherry picks back from master to an old stable branch.

Steps to reproduce

  1. Push a git branch to a fork of a project
  2. Follow the link given by the server to open a new MR (e.g. https://gitlab.gnome.org/pwithnall/glib/merge_requests/new?merge_request%5Bsource_branch%5D=testing-mrs)
  3. Fill in the title, description, milestone, labels, etc.
  4. Remember that you want to target a branch other than master; click ‘Change branches’ and change the target branch
  5. Once the target branch has been changed, you’re back at the new merge request form, but the title/description/milestone/labels/etc. you typed before are gone.
  6. Weep gently

Example Project

https://gitlab.gnome.org/pwithnall/glib/merge_requests/new?merge_request%5Bsource_branch%5D=testing-mrs

GitLab 11.6.

What is the current bug behavior?

Unsaved merge request data is lost.

What is the expected correct behavior?

Unsaved merge request data is saved and restored to the fields when coming back from choosing a target branch.

or

Target branch entry is ordered before other fields on the new merge request form, so people are likely to fill it out before spending time writing a new title/description/whatever.

or

GitLab magically knows which target branch to select by default, so you never need to actually change it. (This is unlikely.)