The page jitters slightly when opening a section with section editing enabled on mobile VE
|mediawiki/extensions/MobileFrontend : wmf/1.33.0-wmf.21||mobile.init/editor: Fix animation when visual section editing enabled on mobile only|
|mediawiki/extensions/MobileFrontend : master||mobile.init/editor: Fix animation when visual section editing enabled on mobile only|
- Mentioned Here
- T69047: VisualEditor: Image should not change size when going from read to edit
T202991: Auto-correct first word in heading breaks view-model sync on iOS
T218436: Differences between read mode and edit mode on mobile: inconsistent underlines under top-level heading
T218437: Differences between read mode and edit mode on mobile: some headings shifted by 1px up or down
@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).
- 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.
Jittery frames for reference: