Change 496066 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/MobileFrontend@master] mobile.init/editor: Fix animation when visual section editing enabled on mobile only

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

Change 496066 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] mobile.init/editor: Fix animation when visual section editing enabled on mobile only

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

Change 496072 had a related patch set uploaded (by Jforrester; owner: Bartosz Dziewoński):
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.21] mobile.init/editor: Fix animation when visual section editing enabled on mobile only

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

Scheduled: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190313T2300

Change 496072 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.21] mobile.init/editor: Fix animation when visual section editing enabled on mobile only

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

Mentioned in SAL (#wikimedia-operations) [2019-03-13T23:41:27Z] <catrope@deploy1001> Synchronized php-1.33.0-wmf.21/extensions/MobileFrontend/: Fix animation when visual section editing enabled on mobile only (T218167) (duration: 00m 58s)

Fix should be live in production now, on wikis running wmf.21 (e.g. testwiki, mediawiki.org).

@matmarex: I am still noticing this for some cases, can you try opening the sections "Heading", "sub-heading 3", "sub-heading 4" using section edit links on my sandbox here: https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&redirect=no

Maybe it's happening for sections which has a focusable node as the first item?
But it does not happen for "Page Title" or "sub-heading 1".

I don't think these are problems with the animation itself, but instead minor differences in styling between read mode and edit mode that become apparent when you swap between modes in this way. I filed separate tasks for them (see below); I think we can check off this task and consider whether we should work on these later.

I recorded some videos (using Chrome on desktop for convenience) and took some screenshots from them.

Issues I see:

• Image size differs
  
  (only if you have a non-default size set in preferences, like I do)
  
  Task already exists T69047

• There is no underline under == heading in read mode
  
  In read mode, only top-level headings on a given page are underlined (the same headings control section collapsing). Usually, this will be the == headings, but on your test page, = is top-level ("Page heading"), and on another page === may be the top-level heading.
  
  In edit mode, this is hardcoded and == headings are always underlined. It might not be trivial to mark each heading with whether it should have an underline or not to match the read mode (it should be feasible, but I think it'd require some JS work and not just a CSS change).
  
  Filed T218436

• Sub-headings and below (===) seem to shift by 1px up or down
  
  In read mode, to position the section edit links exactly where we want them to be, the headings are wrapped in another element with display: table.
  
  In edit mode we can't use display: table, because it causes issues with the editable surface in iOS Safari (T202991). We replicate the same effect using other CSS properties, but as you noticed, the effect is not perfectly identical. We discussed this briefly in code review of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/489379 but at the time decided that it was good enough. We could certainly revisit it, it should not be difficult to fix, just tedious.
  
  Filed T218437

Jittery frames for reference:

Heading
sub-heading 3
sub-heading 4

Okay, since we are tracking the remaining issues on separate tasks, I think we can close this one.