I don't know of any user impact due to this issue.

This is still a problem.

^ I removed the original AC and contradictory first developer note and replaced 'em with the AC that I think we agreed to.

Change 355168 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@master] Title is not properly set inside ApiMobileView

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

This issue is not as easy as it looks like. There is a problem with cache and handling $title objects in ApiMobileView and ParserOutput. First I thought it's related to article protection but I couldn't reproduce it locally, so I from time to time I was refreshing the production to see the API output - but the production sometimes worked properly (was returning the correct edit link) and sometimes was returning the Badtitle one without any obvious reason. This is not an Article protection issue as it would fail all the time.

Reason: With some debugging and thanks to @Legoktm help we found out that ApiMobileView sometimes (depends on cache) calls ParserOutput::getText() which calls Skin::doEditSectionLink().
The Skin::doEditSectionLink() uses $skin->getTitle() which uses RequestContext::getTitle() which defaults to $wgTitle set inside api.php php file (doesn't use the $title created in ApiMobileView)

Solution: Pass newly created $title object to RequestContext class.

Anyone knows how to re-produce the issue locally?

Instructions to replicate

• Setup wiki with memcached https://www.mediawiki.org/wiki/Memcached#PHP_client_for_memcached
• Visit page in Vector/desktop view
• Trigger view to API in form of http://localhost:8888/w/api.php?action=mobileview&format=json&page=Blablablab&prop=text&sections=all

Piotr's fix

I should note Piotr's change (now merged) retains the edit section links but ensures they point to the correct place.

However....

• The edit link repeats information provided elsewhere by the same api query
• Is it useful to include the edit link given that edit links are easy to create from the id property? I suspect apps/other consumers who don't want to show it have to hide the link via CSS.
• Do we want to strip edit-page from the output or leave that up to the client ?

Let's decide this and implement any decision (if needed) before moving to sign off.

Change 355168 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Title is not properly set inside ApiMobileView

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

Current fix do not strip the link as

• issue was somewhere else, first I'm trying to fix the root cause - $title object is not passed to Core
• production sometimes was showing correct link, sometimes incorrect - I decided to keep the old but fixed behavior. First, we thought that it always shows incorrect link
• stripping is not so easy as ParserOutput doesn't operate on SkinMinerva, we will need another hack here (injecting SkinMinerva) in ApiMobileView.

Stripping edit links would be pretty easy if we pass SkinMinerva to ParserOutput

Mass-moving all items tagged for MediaWiki 1.30.0-wmf.3, as that was never released; instead, we're using -wmf.4.