Page MenuHomePhabricator

[Bug] Auto expanding text area causes editor to lose editing position
Closed, ResolvedPublic3 Estimated Story Points


Steps to reproduce

Visit the Boat Race and open the editor. Scroll down the editor and select somewhere at the very bottom of the editor

Type "the cat sat on a very long line and sat on the mat" (text input that jumps to a new line). If the behaviour is correct this should not be a jarring experience. If the behavior is incorrect you may see the text area jump and lose the line you were typing.

Since remote work is hard the bug is demonstrated here: (sorry about the sound - please mute but hopefully it's self explanatory but first I show it working correctly, I then scroll the window and type a sentence at the bottom which I later highlight (with confusing results - that's the jarriness!) I then switch tabs and show how it could behave with the bug fix in the developer notes)


Type any character and the text area will jump and it will not be possible to see what is being typed any more.
Press enter or space key - text area jumps upwards. Cursor is in middle of screen. Type any other key - the newly inserted character is anchored to the bottom of the screen
Click the text area again in (the middle of the space between top and virtual keyboard) to remedy the problem.


Put caret cursor position on last line of textarea and hit enter. Text jumps to the middle. Expected: Should jump 1 line


Scroll down the text area. Press any key and it will scroll back to the top.

editor.gif (646×422 px, 287 KB)

Expected results

Pressing space or enter should not jar the user

Actual results

Environments observed

  • Android 6.0.1 Nexus 5 ; Samsung Galaxy S6
  • IE11
Bug free


Developer notes

This seems to relate to the auto-expanding behaviour of the text area given it only happens when typing near the bottom.

The offending code lives inside EditOverlayBase::_resizeEditor and the call OO.ui.Element.static.getClosestScrollableContainer which should resolve to document, but doesn't.

This JS Fiddle demonstrates the problem in IE 11:
scrollTop is always 0 so typing will always jump to the top. This should be easy to fix.

In Chrome mobile it seems the problem relates to this.$scrollContainer being undefined which results in us calling


on every key press which then fights with the browser defaults.

In the case of Chrome mobile and IE11 this should correspond to $( document ) and should be updated.

Event Timeline

Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson set the point value for this task to 3.Apr 3 2018, 4:26 PM

Risk associated because various devices involved and aged of ticket so 3.

Change 423793 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Do not set scrollTop as undefined in editor

Change 423793 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Do not set scrollTop as undefined in editor

Jdlrobson added a subscriber: ABorbaWMF.

@ABorbaWMF could you please take a look in a few Android and iOS devices and try editing (tops and bottoms of sections) and verify that when you type, where the text appears is predictable and visible to the user? Before, the press of a key was throwing the user all over the place - and they wouldn't be able to see the text they were typing
Please test this one on the beta cluster (

Appears to be working for me on Beta. I tried a few real devices and a few simulated ones. Saw no line jumping.

ovasileva added a subscriber: ovasileva.

Looks good to me! @ABorbaWMF - just a quick confirmation that you were able to test on the browsers mentioned in the task (since I can't confirm from my side)

@ovasileva Tested my own sandbox on IE11 on Windows 7, and it works well.