STR

1. New message, reduce width of TB application window to something like 16cm
2. Type |Dr. Michael Müller-Lüdenscheidt <michael@mueller-luedenscheidt.foo>| (sorry, you really have to type, as this bug does not seem to occur for copy and paste)

Actual result

• UI elements on the right side of the addressing area (e.g. recipient type buttons, Attach button, subject etc.) are pushed out of screen

Expected

• don't push UI elements out of screen

Interestingly, as you keep trying, it even occurs when the actual text entered is way shorter than the available space in the recipient container. Something wrong here wrt auto-width.

(In reply to Thomas D. from comment #0)

Interestingly, as you keep trying, it even occurs when the actual text entered is way shorter than the available space in the recipient container. Something wrong here wrt auto-width.

Whilst we are here, please also address the following:

• Pressing keys that don't produce a visible character and/or don't change the actual length of the input string shouldn't change the width at all.

E.g.:

• Add some pills to fill first row, then at the final rowInput, type "foobarbaz".
• Place cursor at the start of rowInput, in front of "foo".
• Hold DELETE key for a little longer, and monitor cursor and attachment button

Actual result

• cursor ends up below the first row (but we never typed anything!)
• attachment button moves out of sight (dito).

Expected:

• keypresses that don't produce visible characters and/or don't actually change the length of the input string shouldn't move anything around!
• e.g. for the particular case of DELETE, width should only decrease if the length of the input string gets shorter (for as long as we're deleting characters). Certainly it should never increase.

(In reply to Magnus Melin [:mkmelin] from comment #3)

+ ![37, 38, 39, 40].includes(event.keyCode)

keyCode is deprecated. would be clearer to use .code and compare to
"ArrowLeft" etc.

Or maybe just use .key instead? Sweet and simple, even more readable imo, and we're already using that elsewhere. For the keys in question, the return value of .code and .key is the same, "ArrowLeft" etc.

The browser_ext_messageDisplay.js test timed out, but it works properly on both Linux and macOS locally.
Also, this patch doesn't touch this section so I doubt is related.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/79c715e3ece3
Prevent elements overflowing outside the window dialo when dealing with long address pills or input fields in the compose messenger. r=mkmelin