| Etonkovidova | |
| Wed, Oct 23, 2:34 AM |
| F57636614: Screenshot 2024-10-23 at 13.35.04.png | |
| Wed, Oct 23, 11:49 AM |
| F57636271: image.png | |
| Wed, Oct 23, 9:18 AM |
| F57636223: image.png | |
| Wed, Oct 23, 8:54 AM |
| F57635344: prod_mobile_notLoading.gif | |
| Wed, Oct 23, 2:34 AM |
Steps:
Note:
I can reproduce the problem on testwiki, unsure what the cause is. When I try to edit another article, I get an "Editnotice links" pop-up:
Is that supposed to be there? If it is unexpected, could that be what colliding with our UI?
could it be similar to T377783?
Unlikely. The problem in T377783 was triggered by the main namespace being excluded in the HelpPanel configuration in both reading and editing mode. As far as I can tell, that is not the case on https://test.wikipedia.org/wiki/Special:CommunityConfiguration/HelpPanel
I'm noticing that the editor keeps making the same two VisualEditor requests:
But their responses _look_ fine to me at first glance. Though I have no idea they are supposed to look like.
I tried it on dewiki and there the mobile interface works. I looked for the API GET-request above and compared them to test-wiki, and so only difference that looks maybe meaningful is that testwiki has a notice with key editnotice-0, and dewiki as a notice with key flaggedrevs_editnotice. Are we maybe handling flaggedrevs_editnotice but not editnotice-0 or something?
The editnotice seems to be a red herring. It exists on mobile already for at least half a year (see T312587: Show edit notices within mobile editing interfaces), and the respective page on testwiki was last edited 2019: https://test.wikipedia.org/w/index.php?title=MediaWiki:Editnotice-0&action=history
I'm not actually sure how to investigate this further at this point. I'm marking it as a trainblocker, and will be highlighting it to the web team (because mobile) and editing team (because VisualEditor).
Any ideas welcome.
I can reproduce locally, seems related to the mobile editor initialization. Apparently loadVisualEditorMaybe() is being called "recursively". The latest router changes could be the culprit as I see the history state accumulating re-loads of the same URL/hash.
Maybe @Esanders can help us understand what changed.
Change #1082472 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/GrowthExperiments@master] StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events
I can reproduce the problem on testwiki, unsure what the cause is. When I try to edit another article, I get an "Editnotice links" pop-up:
Is that supposed to be there? If it is unexpected, could that be what colliding with our UI?
Yes, that Edit notice popup (the popup varies in how it looks) is kind of curios. It's not new, and seems to be present only testwiki.
Change #1082472 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events
@Esanders Is a cherry-pick of https://gerrit.wikimedia.org/r/1082472 to wmf/1.43.0-wmf.28 sufficient to unblock the train?
Change #1082503 had a related patch set uploaded (by Urbanecm; author: Esanders):
[mediawiki/extensions/GrowthExperiments@wmf/1.43.0-wmf.28] StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events
Change #1082503 merged by Urbanecm:
[mediawiki/extensions/GrowthExperiments@wmf/1.43.0-wmf.28] StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events
Mentioned in SAL (#wikimedia-operations) [2024-10-23T17:31:18Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1082503|StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events (T377907)]]
Mentioned in SAL (#wikimedia-operations) [2024-10-23T17:33:52Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1082503|StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events (T377907)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Tested at testwiki while backporting this, seems to work there as well. Should land within a couple of minutes!
Mentioned in SAL (#wikimedia-operations) [2024-10-23T17:43:15Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1082503|StructuredTaskMobileArticleTarget: Fix history hacks to avoid firing events (T377907)]] (duration: 11m 56s)