Juliusz's thoughts: Height of tabs not taken into account? Too many things going on at the same time (keyboard not yet open so doesn't take into account its height properly)?

Change 150727 had a related patch set uploaded by JGonera:
Delay calculating available area height when keyboard opens

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

Change 150727 merged by jenkins-bot:
Delay calculating available area height when keyboard opens

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

Verified the fix on Betalabs

This one is not working on test2 for some reason :(
test2 is running wmf16 now

jgonera wrote:

This is happening because iOS Safari doesn't fire the "focus" event the first time CE is focused (or something prevents the propagation of the event). Might be somewhat related to the bug about the cursor being moved to the beginning of CE (bug 66697).

jgonera wrote:

ve.ce.Surface.prototype.onFocusChange seems to be stopping the propagation of "focus" event when CE is focused for the first time. Making ve.ce.Surface.prototype.onFocusChange a noop fixes this bug (but is obviously not the right solution).

jgonera wrote:

More precisely it's ve.ce.Surface.prototype.onDocumentFocus.

jgonera wrote:

Reverting 71395e1f (https://gerrit.wikimedia.org/r/#/c/139677/) fixes this bug but brings back bug 65928. Need to consult with Ed.

jgonera wrote:

Digging deeper into the rabbit hole...

• Commenting out "this.emit( 'select', this.selection && this.selection.clone() );" in ve.dm.Surface.prototype.setSelection also fixes the bug. It also seems to be fixing bug 66697.

• Making ve.ce.Surface.prototype.onModelSelect a noop also seems to fix both bugs.

• Commenting out "this.showSelection( selection );" ve.ce.Surface.prototype.onModelSelect seems to fix both bugs too.

I suspect we're either doing something weird that iOS Safari doesn't like or perhaps there is a bug in Rangy.

jgonera wrote:

This is weird. I tried following the call stack deeper to see what exactly causes the problem, but I'm stuck in ve.ce.Surface.prototype.showSelection.

It seems I have to comment out:

if ( this.getElementDocument().activeElement !== documentElement ) {

		documentElement.focus();

}

plus at least _one_ (either or both) of the following:

		rangyRange.setStart( selection.start.node, selection.start.offset );
		rangySel.setSingleRange( rangyRange );

I'm wondering if iOS Safari has some weird bug where it drops events when something tries to modify the same DOM node too many times.

Change 155678 had a related patch set uploaded by JGonera:
[WIP] Do not focus CE on mobile when editor opens

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

Change 155678 merged by jenkins-bot:
Do not focus CE on mobile when editor opens

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

Still not working for me.I tried on this page: http://en.m.wikipedia.beta.wmflabs.org/wiki/21staugustchrome

But it's reproducible for any page.

jgonera wrote:

We might need to wait unitl https://gerrit.wikimedia.org/r/#/c/155671/ is merged.

Change 155671 had a related patch set uploaded by Jforrester:
Don't trigger focus event on contenteditable in VE

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

Change 155671 merged by jenkins-bot:
Don't trigger focus event on contenteditable in VE

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

Maybe now?

The issue got resolved for the aforementioned steps , but still it is occurring for the following case

1.Open the page.
2.Tap on an existing link from the page.
3.Open the link inspector when the context menu for it appears.
4.Just close the link inspector tapping on the "Done" button.
5.Now tap anywhere in the CE.

You will see the toolbar did not float this time.

It happens after opening and closing citation dialogs as well

Also , as Roan specified in https://bugzilla.wikimedia.org/show_bug.cgi?id=68828

After coming to CE and tapping somewhere , the scrolling to the top of the page does not work,which might be related to this issue.So we are keeping both the issues in same place for now and closing the other one.