Page MenuHomePhabricator

AMC Outreach Drawer encouraging me to turn on advanced mode sends me from Special:Homepage to my user page
Closed, ResolvedPublic

Description

I visited Special:Homepage on mobile beta labs and got a popup encouraging me to enable advanced mode. When I agreed, it reloaded the page in advanced mode, but it sent me to my user page instead of Special:Homepage. (Perhaps this is because we set the relevantTitle of Special:Homepage to the user page?)

Steps to reproduce

  1. Open a new incognito window,
  2. Login to https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Homepage as a user with AMC disabled
  3. When the outreach drawer appears, click the "Enable advanced mode" button
  4. Notice that you are redirected to the user page instead of back to Special:Homepage

Expected results

  • User is redirected back to the page they enabled AMC from (in this case Special:Homepage)

Actual results

  • User is redirected to user page

Dev notes

The amc outreach form uses currentPage.js to determine an appropriate redirection. currentPage.js [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/b16895f9483c5949cd18d8b3f8400245f9b1952b/src/mobile.startup/currentPage.js#L25 | uses wgRelevantPageName ]] to determine the current page's title:

mw.Title.newFromText( mw.config.get( 'wgRelevantPageName' ) );

Pages like Special:Homepage and Special:WhatLinksHere can set [[ https://www.mediawiki.org/wiki/Manual:Interface/JavaScript | wgRelevantPageName ]] to something other than the current page's title, however which is why this bug is occurring.

Possible solutions

  1. Use [[ https://www.mediawiki.org/wiki/Manual:Interface/JavaScript | wgPageName ]] instead of wgRelevantPageName to determine the page to redirect back to. This is what https://gerrit.wikimedia.org/r/531743 attempts to do. This might be simplest solution, however if the user lands on a page with other query params (besides title), these would get dropped upon redirection. We could add another query param returntoquery to prevent this from happening which is what the login link does, but this will probably require some messy/unfun finagling of query params.
  1. Use the entire relative path to determine what page to redirect to. This is what https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/531588/ attempts to do, but it seems that using returnto/returntoquery is the popular way to handle this within the mediawiki ecosystem
  1. Use an ajax request to perform the POST and then refresh the page once successful. However, we would probably have to show a spinner while the request is performed and may have to handle any error messages from the backend. I also think a spinner followed by a full page refresh can be a little jarring to the user.

QA Results

ACStatusDetails
1T230927#5468134

Event Timeline

Catrope created this task.Aug 21 2019, 1:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 21 2019, 1:35 PM
Jdlrobson assigned this task to Catrope.EditedAug 21 2019, 4:36 PM
Jdlrobson added subscribers: Esanders, Jdlrobson.

The form is creating a link to the user page "/w/index.php?title=Special:MobileOptions&returnto=User%3AJdlrobson"

This is using:

mw.mobileFrontend.require('mobile.startup').currentPage()

which does indeed use wgRelevantPageName:

mw.Title.newFromText( mw.config.get( 'wgRelevantPageName' ) );

@Catrope I'm not sure what the reason for using wgRelevantPageName was there but is there a strong reason Special:MobileHomepage sets wgRelevantName ? Is the code above wrong or is Special:HomePage wrong?

wgRelevantPageName was added in T217826 by @Esanders in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/494907/

nray added a comment.Aug 21 2019, 6:36 PM

I did some testing of the outreach drawer on the Special:WhatLinksHere page (e.g. http://localhost:8181/w/index.php?title=Special%3AWhatLinksHere&target=Test&namespace=) which https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/494907/ cites as the reason to use wgRelevantPageName, but it seems that wgRelevantPageName points to the actual article instead of back to the 'Special:WhatLinksHere' page in this scenario so there is buggy behavior on this page as well.

Additionally, even if we used wgPageName instead of wgRelevantPageName, the query params would still be dropped and the user would be redirected back to the plan Special:WhatLinksHere page once they enabled AMC through the form.

Now, I'm wondering if the form should just be using an absolute url for the returnto query param to account for these cases and if using wgPageName/wgRelevantPageName is futile.

Change 531588 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/extensions/MobileFrontend@master] 🐛 Fix Amc Outreach Drawer Redirection

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

nray renamed this task from Popup encouraging me to turn on advanced mode sends me from Special:Homepage to my user page to AMC Outreach Drawer encouraging me to turn on advanced mode sends me from Special:Homepage to my user page.Aug 22 2019, 5:00 PM
nray updated the task description. (Show Details)
nray updated the task description. (Show Details)Aug 22 2019, 6:10 PM
nray updated the task description. (Show Details)
nray updated the task description. (Show Details)Aug 22 2019, 6:14 PM
nray updated the task description. (Show Details)Aug 22 2019, 6:16 PM

Change 531743 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] currentPage should reflect currentPage not relevant title

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

nray updated the task description. (Show Details)Aug 22 2019, 8:11 PM

Change 531588 abandoned by Nray:
🐛 Fix Amc Outreach Drawer/BetaOptInPanel Redirection

Reason:
we probably wont use this

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

Change 531743 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] currentPage should reflect currentPage not relevant title

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

Jdlrobson reassigned this task from Catrope to Edtadros.Aug 29 2019, 7:40 PM
Jdlrobson updated the task description. (Show Details)
Etonkovidova added a subscriber: Etonkovidova.EditedAug 29 2019, 9:36 PM

Checked in betalabs - the issue seems to be fixed:

@Jdlrobson/@nray I cannot get the outreach drawer to appear. Is there something else I need to do besides make sure that AMC is not on?

nray added a comment.EditedSep 3 2019, 3:45 PM

@Jdlrobson/@nray I cannot get the outreach drawer to appear. Is there something else I need to do besides make sure that AMC is not on?

Are you testing when logged into https://en.m.wikipedia.beta.wmflabs.org and with AMC off? In production, you will need to have made at least 100 edits in order to see it so make sure you are testing beta (which allows people with >= 0 edits to see it). If you are testing beta and still don't see it, you might already have a localStorage entry. To get around this, you can:

  • After making sure you have AMC turned off, close all previous incognito windows and open up a new incognito window. Log into your account, and you should see it.
Edtadros reassigned this task from Edtadros to ovasileva.Sep 5 2019, 2:33 PM
Edtadros added a subscriber: Edtadros.

Test Result

Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome
Device: MBP
Emulated Device: iPhoneX

Test Artifact(s):

QA Steps
  1. Open a new incognito window,
  2. Login to https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Homepage as a user with AMC disabled
  3. When the outreach drawer appears, click the "Enable advanced mode" button
  4. ✅ AC1: User is redirected back to the page they enabled AMC from (in this case Special:Homepage)

Edtadros updated the task description. (Show Details)Sep 5 2019, 2:33 PM
ovasileva closed this task as Resolved.Sep 5 2019, 3:56 PM

looks good!

DannyS712 added a subscriber: DannyS712.

[batch] remove patch for review tag from resolved tasks

Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptNov 18 2019, 11:36 AM