| matmarex | |
| Oct 7 2019, 11:58 PM |
| F31621385: en.m.wikipedia.beta.wmflabs.org_wiki_Dog(iPhone X).png | |
| Feb 18 2020, 5:19 PM |
| F31613523: image.png | |
| Feb 12 2020, 9:31 PM |
| F31613520: image.png | |
| Feb 12 2020, 9:31 PM |
| F31552251: Dog - Wikipedia, the free encyclopedia (1).gif | |
| Feb 6 2020, 3:34 PM |
| F31552249: Dog - Wikipedia, the free encyclopedia.gif | |
| Feb 6 2020, 3:34 PM |
Mobile VE no longer restores section hash fragment after section editing.
Actual behavior
Expected behavior
Video
https://youtu.be/fikbhfZjmJE
| AC | Status | Details |
|---|---|---|
| 1 | ❓ | T234868#5856482 |
When we save the page, we get the new page HTML from the action=parse API, and we search that HTML for the section number we used for editing (e.g. "9" in https://en.m.wikipedia.org/wiki/Frederick_Law_Olmsted#/editor/9) to get the section id (e.g. "U.S._park_designer" in https://en.m.wikipedia.org/wiki/Frederick_Law_Olmsted#U.S._park_designer).
As it turns out, in Minerva the API returns different HTML, which prevents us from finding the right section. Compare:
This seems unintentional, and might be a bug in 54060a3c (T206265: Bug: Section edit links should be hidden for blocked users).
Change 541597 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] ApiParse: Use the right Skin object for building section edit links
Change 541598 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Allow passing context to MinervaPagePermissions
Change 541597 merged by jenkins-bot:
[mediawiki/core@master] ApiParse: Use the right Skin object for building section edit links
The Minerva patch still needs to be merged: https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/541598
Change 541598 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Allow passing context to MinervaPagePermissions
Status: ❓
OS: macOS Catalina
Browser: Chrome
Device: MBP
Emulated Device: iPhoneX
Test Artifact(s):
Edit the body of a section
Publish changes
❓ AC1: View is scrolled to the top of the section I was just editing
This doesn't scroll the section at the top of the view but towards the top of the view. I tried it with starting the edit while the section was near the bottom of the view and when it publishes it goes back to the location/view in the gif above.
@Edtadros Does that also happen to you when directly viewing the page, i.e. after clicking this link: https://en.m.wikipedia.beta.wmflabs.org/wiki/Dog#Biology? if so, it's out of scope (but maybe another task should be filed).
I could reproduce something similar and it appears to be caused by the annoying survey box loading late and shifting the page's contents:
| After loading the page | …The offset of the header suspiciously matches the height of the annoying survey box |
 |  |
Luckily we don't have that in production (and I hope we never will, why is that even there?).
Seems like this is also in QA on the Editing board so will untag the Web kanban board for now. Feel free to add us again if this is premature/there's more needed from our side.
