Page MenuHomePhabricator

Session not created on VoteWiki when using desktop site with a mobile user agent
Closed, ResolvedPublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

Order may be very important here:

  1. Start a new private browsing session in Firefox
  2. Enter responsive design mode (Crtl-Shift-M)
  3. Select "iPad" from the drop-down
  4. Go to https://en.wikipedia.org/
  5. Click the "Desktop" link at the bottom of the page
  6. Log in to an account eligible to vote in the current ArbCom election
  7. Go to https://en.wikipedia.org/wiki/Special:SecurePoll/vote/801
  8. Click "Go to the voting server"

What happens?:

I am taken to https://vote.m.wikimedia.org/wiki/Special:SecurePoll/vote/1303 and see "You must log in to vote in this election - please try following the link from your Special:SecurePoll on your local Wikimedia site."

What should have happened instead?:

I see "Welcome Suffusion of Yellow!"

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 in responsive design mode, simulating "iPad", Mozilla/5.0 (iPad; CPU OS 14_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1)

Others have reported this on "real" mobile devices, see https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1056840719#Unable_to_login_to_the_secure_poll_for_the_ACE

Workaround (2022)

Some editors have reported that "changing back to the desktop view on VoteWiki" (i.e. clicking the "desktop" link in the footer on VoteWiki) allows them to then vote successfully — the "desktop" link goes to https://vote.wikimedia.org/w/index.php?title=Special:SecurePoll/vote/1402&mobileaction=toggle_view_desktop, and visiting that URL directly may work for you if you are already logged in.

Event Timeline

Confirming (a) that I can replicate the issue following Suffusion's report above, and (b) I encountered the issue "in the wild" when attempting to vote. I use iOS, Chrome, and the Monobook (responsive) skin for what it's worth. I was able to vote by changing back to the desktop view on VoteWiki IIRC.

jrbs triaged this task as High priority.Sep 23 2022, 10:16 PM
jrbs moved this task from Backlog to Needs evaluation on the MediaWiki-extensions-SecurePoll board.
jrbs lowered the priority of this task from High to Medium.Sep 23 2022, 11:09 PM

I can confirm this. I faced this same issue earlier at 12:37 UTC, but it has now automatically resolved (at least for myself) as of 22:00 UTC.

Another workaround is to switch to mobile view on Wikipedia before you're jumped to votewiki. (This is unfortunately still an issue.)

kostajh added subscribers: Tgr, kostajh.

@Tgr is it possible that this is/was CentralAuth related, and might be fixed from recent bug fixes to CentralAuth extension?

Could someone try to reproduce this bug again, please?

We don't edge login on votewiki; this is the current list. It wouldn't work in Firefox anyway. (See T345249: Mitigate phase-out of third-party cookies in CentralAuth for the wider issue and mitigation plans, but nothing short-term.) So probably not fixed as defined by the exact reproduction steps in the description; but T326281: Attempt top-level central autologin when visiting the login page (to allow autologin when the browser blocks third-party cookies) should have made the impact smaller. T257852: CentralAuth edge login and autologin for some Wikimedia domains broken on mobile fixed some autologin/edge login scenarios for browsers that don't block cross-domain cookies by default (Chrome, Edge, Opera at this point), mainly when the original login happened on a wiki with a different mobile domain pattern (like Wikidata).

Tgr claimed this task.

I'll close this as I think the issue is partially fixed, and partially a browser limitation with no easy fix (and we have already have a task for the hard fix). Please reopen if you still encounter unexpected issues (top-level autologin doesn't work; or normal autologin / edge login doesn't work in Chrome / Edge / Opera; see defnitions here).