From the apps' point of view, we'll just need to agree on an outgoing and incoming URL to deal with the handoff and return from VE, respectively.

The outgoing URL (from app to VE) would look something like this:
https://en.wikipedia.org/wiki/Cat?useformat=mobile&veaction=edit&returntoapp=true

• Note the extra parameter returntoapp=true, which tells VE that it will need to redirect back to the app when finished.
• Question: is useformat=mobile&veaction=edit correct? Or should it be something different?
• Question: if the user needs to login or create an account within the VE workflow, will this URL survive those actions?

The incoming URL (from VE to app) would look like this:
wikipedia://en.wikipedia.org/wiki/Cat?saved=true&revision=1234

• The wikipedia: scheme makes this URL a deeplink, and will be directed to the app by the OS.
• The domain and path of the URL are the current page itself.
• The saved parameter tells whether the edit was published successfully, or abandoned (true/false). The presence of this parameter can also serve as the indication that this URL is returning from VE.
• If the edit was published, the revision parameter is the new revision ID.

Once the app receives the incoming URL, it will come to the foreground and deal with the URL and parameters as necessary.

@DLynch Any thoughts / tweaks / concerns?

Question: is useformat=mobile&veaction=edit correct? Or should it be something different?

useformat might be overkill -- do you actually want larger tablet users to be forced into the mobile version of the site that they wouldn't normally get?

Question: if the user needs to login or create an account within the VE workflow, will this URL survive those actions?

I believe that it should, or at least is intended to. It'd be subject to occasional glitches in our bounce-to-auth.-then-bounce-back flow which I'd hesitate to rely on 100%.

I might need to verify that the parameters are actually being passed through and not just the article URL, but I'm pretty sure they are.

Editing is going to pick this work back up during the sprint that begins on May 11 so that we can create space to participate in the Sprinthackular.

@Dbrant, if the above presents any issues for apps, please let us know here or send me a DM!

I might need to verify that the parameters are actually being passed through and not just the article URL, but I'm pretty sure they are.

I was wrong about this. Or, rather, I was thinking of the desktop version of this, which does preserve parameters in the editnotice it shows to logged out users. Though only for source mode edits, visualeditor's pathway to building the notices discards the original URL.

MobileFrontend, by contrast, does this:

params = util.extend( {
	returnto: options.returnTo || (
		// use wgPageName as this includes the namespace if outside Main
		mw.config.get( 'wgPageName' ) + '#/editor/' + ( options.sectionId || 'all' )
	)
}, options.queryParams ),

I don't think that options.returnTo is ever actually provided, so the query string is always discarded. We could revisit how T298323 was resolved and try to pass some of this through, but my impression of that task is that this is fairly fragile and caused problems at the time.

Potential complication: what should happen if a logged out user had a temp account created for them?

Change #1305261 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] Editor: if a returntoapp parameter is given redirect to the app

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

Change #1307817 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] MobileArticleTarget: store the savedRevId for MobileFrontend

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

Hi @DLynch! I am slowly onboarding myself with this project and have some questions. Please let me know what you think when you can, thanks!

1. Design had concerns with having a redirect at all because if there are any publishing errors, the user won't be able to read them before they redirect to the app. Would this happen? I was thinking the redirect wouldn't occur upon a publishing error (only upon success), so they'll be able to stay in mobile web and read the error.
2. I think one remaining issue to resolve is continuing to pass along the redirect query item through login / create an account. Let me know if there are other things you can think of that are blocking.
3. In my prototype (hitting https://5c92b063e0.catalyst.wmcloud.org/wiki/Cat?veaction=edit&section=0&returntoapp=1), I notice my very first fresh attempt (i.e. new app install, reset browser) seems to show the Desktop view in Safari, and the redirect doesn't work post-publish. When I try a second time it does work. Do you think this might just be a quirk with patchdemo? I can re-test once things are deployed but wanted to flag in case it's a deeper issue.

https://drive.google.com/file/d/1bop3cR2qvKXyXEok2yInOVwbdpqf2bfK/view?usp=drive_link

Design had concerns with having a redirect at all because if there are any publishing errors, the user won't be able to read them before they redirect to the app. Would this happen? I was thinking the redirect wouldn't occur upon a publishing error (only upon success), so they'll be able to stay in mobile web and read the error.

Yeah, the redirect back to the app would only happen once the editor was exited. This should only happen if the user successfully completes a save, or deliberately backs out of it via the X button.

I think one remaining issue to resolve is continuing to pass along the redirect query item through login / create an account. Let me know if there are other things you can think of that are blocking.

Indeed, we need to rewrite the way that passthrough is being done to cope. Either make it more generic so it passes through everything, or just tell it specifically about this parameter.

I notice my very first fresh attempt (i.e. new app install, reset browser) seems to show the Desktop view in Safari, and the redirect doesn't work post-publish. When I try a second time it does work. Do you think this might just be a quirk with patchdemo?

I think that's most likely to be a patchdemo issue. However, if we really want to force it, the app could explicitly add useformat=mobile to the URL parameters it's generating. The side-effect would be that it'd result in anyone who qualifies for the desktop site because they're using a large tablet (which I think works?) would also be forced onto mobile. Might be entirely reasonable for a consistent experience.

@DLynch sounds good, thanks for the quick response.

Indeed, we need to rewrite the way that passthrough is being done to cope.

Do you need a separate task from us for that, or are you all good with continuing to work against this task? Thanks!

In T422075#12133577, @Tsevener wrote:

Do you need a separate task from us for that, or are you all good with continuing to work against this task? Thanks!

A separate task to improve that would be fine by me.

Change #1307817 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] MobileArticleTarget: store the savedRevId for MobileFrontend

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

Change #1305261 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Editor: if a returntoapp parameter is given redirect to the app

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

@DLynch

New task for authentication is here - T432659: [REQUEST] Allow returntoapp and appinstall parameter to pass through authentication flow, thanks!

Wrong info on task. Please ignore.