MTextBox Cursor lags behind when scrolling (IOS)

Skip to first unread message

Spaceman Spiff

Jun 7, 2016, 7:05:22 AM6/7/16
to mgwt

If I give focus to a textbox the cursor of the field starts to blink
Now if I scroll the cursor lags behind and jumps when finish scrollng.
This can be reproduced in the show case.
Is there a workaround?



Jun 7, 2016, 10:42:19 AM6/7/16
to mgwt
Which platform? IOS or all?

I know we have done some work to make text boxes and text areas work better when in a scroll panel. The problem is when you start to mess about with events sourced from a text box e.g. if you call prevent default on the event. It can cause all sorts of issues with the default behaviour of text box supplied by the browser e.g. a blinking cursor, text selection, cut and paste etc

Have you tried showcase against the latest code in the mgwt github repo?


Spaceman Spiff

Jun 7, 2016, 12:01:38 PM6/7/16
to mgwt
Hi Paul,
I'm afraid I did not phrase this correctly.
When I give focus to a textbox and the caret starts blinking, it is good, that's the expected behavior.
But when I start scrolling while the soft keyboard is visible and the textbox is still in focus, then the caret lags behind.

It is in IOS that I have this issue.
In android it works correctly, I believe the reason is because I'm not using the mgwt scollpanel. I can't do the same with IOS because I'm using cell lists and widget lists. 

I'm testing with mgwt-2.0.1-20150221.113309-17.jar

I tried a couple of things.
First I tried to hide the caret when the scrolling starts and then show it again when it ends.
Unfortunately it's not possible to modify the caret with css in IOS. 
Losing focus is no good solution either as it causes the soft keyboard to hide


Jun 8, 2016, 10:20:15 AM6/8/16
to mgwt
Yes, it is a problem and does not look great. If you simply add an input text field to a page, click in the field and then every few seconds randomly move the input field around by using a transform then the blinking cursor does not move with the input text field. So looks like an IOS safari bug.

So I don't have a quick answer. If the scroll panel could track the current element that has focus and when being scrolled calls focus() again on the element that has focus then maybe this would sort it. Just an idea!

Reply all
Reply to author
0 new messages