For context, T46992 should explain why the icon is where it is. For practical purposes, I'd consider this a Flow problem, unless/until it's proven to be intractable with Flow changes, simply because otherwise N other use cases need to be reassessed.

Per Nemo, this is a Flow-specific problem.
AFAIK, No other text-input areas have a critical button/link directly below the bottom-right corner.

We could either:

1. Swap the TermsofUse blurb (to the right) and the [cancel / preview / save] buttons (to the left).

This would be more consistent with the location of the standard wikitext [save page / show preview / show changes / cancel], and with LQT's [save page / show preview / cancel], which both use the bottom-left as the anchor (in LTR languages).
(Also Gmail has "Send" in the bottom-left. Also https://tools.wmflabs.org/styleguide/desktop/section-1.html#section-1.2 has buttons attached in the bottom-left. )

2. Move the buttons slightly to the side

The IME icon is ~32px wide altogether. The buttons are about 37px high, and 2px away from the text-area. If we moved the buttons 38px left, it would all fit (but look a bit odd).

3. Increase the gap under the text-area

This would create yet-more whitespace, which is already overabundant.

4. Move the IME icon to appear within the text-area instead of underneath it. (Per the merged T69903 and T66733)

See Design Team spec at https://trello.com/c/MC8ovuyw/2-advanced-input-fields

I don't think #4 is viable, because then it would interfere with the text-area-size-adjustment drag-control (used in many of the multi-line text-areas), or the magnifying-icon in the search-text-area. So we'd have to special-case it for Flow.

We've had an updated design for this for some time now, adding it here.

Trello card is here https://trello.com/c/MC8ovuyw/2-advanced-input-fields which also shows how it would look if/when we add fomatting controls as well.

The design that Jared posted works for me. We'll put it in story grooming and get it ready for an upcoming sprint. Thanks!

In T78348#964537, @DannyH wrote:

The design that Jared posted works for me.

If you mean the one above, it seems option #4, so I reiterate:

In T78348#963866, @Quiddity wrote:

I don't think #4 is viable, because then it would interfere with the text-area-size-adjustment drag-control (used in many of the multi-line text-areas), or the magnifying-icon in the search-text-area. So we'd have to special-case it for Flow.

To be clear, we're talking about

What if we pull the icon up and in so it's still balanced margins from bottom and right (or left) edge but out of the hit zone for the resize gripper?

Also weren't we auto sizing the fields to the content?

The current approach was intended to work on whichever input field we needed Input methods for, but it is suboptimal in many cases.
For input elements that follow the design guidelines (in Flow and other extensions), there is enough room for the input menu to be placed inside in a persistent manner (no need to make it fade away) and taking into account browser aids for expanding input areas.

Adding a CSS rule to the IME that is applied to those input elements is a simple solution.

We may also want to consider that nowadays it is common to have similar actions inside input fields (e.g., to attach an image), so it may be worth it to develop a more generic solution. Extend input fields to allow that extensions can include different actions inside input fields, and the framework will be in charge of the layout (e.g., showing 2-3 of them depending on the available space and the rest in an expanded menu). If we don't do this as part of the input controls I can imagine the extensions having ad-hoc code for positioning their icons which will lead to icons overlapping (since not all input elements will have the same actions, positioning won't be trivial) or crowding input fields.

In T78348#974915, @Jaredzimmerman-WMF wrote:

Also weren't we auto sizing the fields to the content?

I think the resize gripper is only disabled in Flow (also the only place with the auto-resize I know of). Hence the question of whether to special-case it for Flow (preferably, not) or find a general solution. The general solution would be a location that is clear of the resize gripper (if it exists).

Change 619818 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Flow@master] Use new ime-position-inside for jQuery.IME

https://gerrit.wikimedia.org/r/619818

Change 619818 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Use new ime-position-inside for jQuery.IME

https://gerrit.wikimedia.org/r/619818