Allow the user to resize the issue and epic description edit area

Problem to solve

When editing issues and epics that have long descriptions (more than 26 lines), I am forced to scroll inside the edit field. This makes the edit experience cumbersome and makes it impossible to see more of the content together in the same view.

Proposed solution

Most modern browsers support user-resizing of the text area by default and users are used to being able to resize the area to fit their screen/work style the best. I propose we enable this feature for the description edit field. This feature is currently being disabled by applying the resize: none style attribute, which may not even be intentional.

The initial height and width should stay the same, so that there is no impact on the users who chose not to resize the field. Max height and width should not be set, as they should be controlled directly by the user.

Mockup

added UX featureenhancement groupproject management labels

added Category:Project Management [deprecated] epics issues labels

changed the description

mentioned in issue gitlab-com/Product#1470 (closed)

I think that would be useful. fyi, there is a full screen icon in the upper right corner of our edit boxes. I only point this out because I didn't notice it until @gweaver pointed it out a few days ago...

Interestingly enough, the "Full Screen" view does not show any more of the text, it just makes it extra large and somehow even harder to edit since there is no longer a way to "Preview" the changes.

"Regular" edit mode:

"Full Screen" edit mode:

Setting label(s) devopsplan sectiondev based on groupproject management.

added devopsplan sectiondev labels

marked this issue as related to gitlab-com/Product#1470 (closed)

added typefeature label

removed featureenhancement label

@dennis, @xanf: This looks like a small/quick change to me. Is there any reason why this wouldn't be a quick UX win?

Seems like quick win for me too. I'm not 100% familiar with codebase obviously but can't see if it could break anything

@xanf @hdelalic

It seems like a quick win, but it's being directly set on the element which could be done by any one of the plugins we use on these inputs:

• Zenmode
• Dropzone
• gfm-input

We would need to spend a fair amount of time taking it dissecting this to figure out what plugin is setting resize: none and why, to determine if we can remove it.

It would move much faster if someone who has more domain expertise with this component could look into it. It's certainly not a 1 weight.

Thanks for the response. Perhaps someone might chime in with the info.

@dennis Thank you, I've had to be more detailed in my research, what I've done before posting my comment. Basically we have "double-shot" here. behaviors/autosize.js and gl_form.js trigger autosize library, which explicitly sets resize: none

Unfortunately library is abandoned and is definitely a ~"technical debt" for us

I've checked behavior of library if we explicitly unset resize :none and was not able to find any issues with library, so for quick & dirty solution... well, let's weight it like and of course it is higher if we decide to proceed with proper technical debt management

@xanf thanks for looking deeper into it. Sounds like we can move forward provided we create another issue to take care of the technical debt.

@xanf Thanks for checking out the quick & dirty solution. Was the user experience exactly the same when first loading the page (i.e. default size)?

@hdelalic yes, the dirty solution comes in play after autosize "autosized" textarea, so first load experience is the same

@xanf This issue is still open. Something to consider in 14.3 if you are looking for a quick win.

@wortschi A candidate for improving the UX?

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

assigned to @xanf

mentioned in issue gitlab-org/manage/general-discussion#17414

added Category:Portfolio Management label

added Category:Team Planning label

Thanks for working on this @xanf! We've removed the Seeking community contributions label to avoid having multiple people working on the same issue.

removed [deprecated] Accepting merge requests label

Pulling this into %14.10 as tiny stretch goal

/cc @wortschi

Thanks @xanf. I'm switching the group to ~"group::import" for tracking purposes.

changed milestone to %14.10

added frontend label

added 1 deleted label and removed groupproject management label

Pulling this into milestone

added Next Up workflowready for development labels

mentioned in issue gitlab-org/quality/triage-reports#7248 (closed)

changed milestone to %15.0

added quad-planningcomplete-no-action label

added groupproject management label and removed Category:Project Management [deprecated] + 1 deleted label

changed milestone to %15.1

added missed:15.0 label

added 1 deleted label and removed groupproject management label

mentioned in issue gl-retrospectives/plan#75 (closed)

@nickleonard this is relevant to the work we are doing for work items.

@hdelalic is this something your group was planning to work on?

@gweaver it hasn't been worked on so far and not planned. Should we move it back to your group?

changed milestone to %15.2

added missed:15.1 label

changed milestone to %15.3

Putting weight here and moving to %15.4

While this originally looked simple, I've figured out that the library we're using (autosize) does not provide a desired behavior. A quick look at other npm libraries revealed that none of them are ready to be dropped instead of autosize so we will need either to create a wrapper (I hope for that) or just fork/update library with required functionality

@xanf Thank you for the estimate. Given that this is a very low priority and doesn't fall directly under ~"group::import" I suggest to move this back to the backlog instead. @iganbaruch WDYT?

@wortschi @xanf fine by me.

I found this issue while looking at &13895.

In the process, I learned that BFormTextarea has an auto-height feature: https://bootstrap-vue.org/docs/components/form-textarea#auto-height. It disables the resize handle when auto-height is enabled, which makes sense.

This also made me think of this bug due to autosize on Safari. I wonder if we could address both things by consuming the auto-height feature of BFormTextarea instead of autosize?

changed milestone to %Backlog

marked this issue as related to #376206 (closed)

mentioned in issue #376206 (closed)

marked #376206 (closed) as a duplicate of this issue

added devopsmanage label and removed devopsplan label

added devopsplan groupproject management labels and removed devopsmanage + 1 deleted label

unassigned @xanf

marked this issue as related to gitlab-ui#2610