Fixes #2422 - Add autogrow to bugform steps to reproduce field

[Regaddi]

r? @zoepage

I decided to expand and reduce the textarea based on the text rows. I set the maximum height to window.innerHeight / 2 as a first best guess, but I'm open to other opinions. If needed we can also make this configurable (e.g. by using a data-attribute on the field).

I also pushed these bits of code into the bugform.js file, but maybe the functionality should be extracted later on (comparable issue like #2268).

[zoepage]

r? @miketaylr
r? @karlcow

[karlcow]

I might be doing something wrong. The only place it worked for me was
Chrome mobile (responsive mode).

[karlcow]

This was tested on http://localhost:5000/issues/new
Let's try on the comments.
Same thing. not working.

→ git status
On branch review-2422
Your branch is up-to-date with 'webcompat/issues/2422'.

npm install and grunt were performed before testing.

[Regaddi]

@karlcow: Have you deleted your cache? I needed to force clear my browser caches. After that it works fine for me in Chrome, Firefox, Safari and Edge.

[Regaddi]

Aha! It's not working as expected, when pasting in longer text. Will check that immediately!

[miketaylr]

Sorry, I've been swamped with other stuff. Will try to find the time for review tomorrow!

[Regaddi]

So I made a few adjustments to have everything set up and calculated correctly.
I use the elements dataset to store some data dynamically, especially the initial rows attribute value and the height per row in pixels (since I don't want to calculate this on each event trigger).

From my side it should be good now: entering text manually and pasting text in increases the text fields height.

Are there any more opinions on @zoepage's comment?
If not, I'd go with her suggestion and decrease the maximum height of the textfield to 1/3 of the screen height.

[karlcow]

@Regaddi Speaking to myself, and creating long comments all the time, the more I can maximize, the better for me. So limiting to an height is not a very good fit for me. Having real estate for working out the prose is good.

[karlcow]

Reading again carefully @zoepage comment to be sure I don't misinterpret it.

i think half of it might be too much, especially on big screens. Maybe 1/3 should be enough?

Maybe the criteria is not the screen height. Probably the thing which matters is the browser height. For example, this is me right now for a comment I have not yet finished.

The height of this screenshot is 3162px and if the comment is getting longer I will probably stretch it even more depending if it helps me to understand visualize my comments with the code.

Hope it helps. So to rephrase my habits:

I maximize the textarea for the current browser height when having long comments of code.
I can see how it would become difficult when the textarea is higher than the viewport and for this, probably limiting to 90% of the browser height would be good.

[miketaylr]

Just testing out the current PR... it seems good to me?

i think half of it might be too much, especially on big screens. Maybe 1/3 should be enough?

Why would we want to limit the height of the textarea? We can always scroll up the page, and that's less annoying than scrolling within a textarea, IMO.

(maybe I misunderstand)

IMO, we should merge this now, and file a follow up bug to improve it if we feel like there's some UX improvements to be gained after experience using it.

Thoughts @karlcow @Regaddi?

[miketaylr]

Ping @karlcow. Any objections to merging now?

[karlcow]

ah missed it. Not tested yet. but let's merge and learn from it.