@Etonkovidova if you have a chance, can you double-check this flow.
Here's the related task that explains the logic I thought was in place: T310320: Account creation + Growth tools: improve UX for newcomers who create an account while mid-edit

I'm wondering if perhaps something changed after the auth / SUL3 work?

In T397193#10923757, @KStoller-WMF wrote:

@Etonkovidova if you have a chance, can you double-check this flow.
Here's the related task that explains the logic I thought was in place: T310320: Account creation + Growth tools: improve UX for newcomers who create an account while mid-edit

Hmm... it seems that now we have a regression issue. I remember that the correct behavior was verified - https://phabricator.wikimedia.org/T310320#8267095

I checked the current behavior (both on mobile and on desktop for testwiki wmf.6. The issue is present:

• a non-logged user starts editing, even making some edits
• a user sees the VE warning and clicks on the "create an account" link in the waring
• when an account is created, a user is presented with Welcome survey. After submitting the Welcome survey or after skipping it, a user is not returned to editing an article.

I'm wondering if perhaps something changed after the auth / SUL3 work?

Maybe it's because of some changes to the temp users workflows?

Estimation: After fixing this, we should make sure to also have an automated test for this user workflow.

I did an archaelogy into why users are incorrectly redirected to the Welcome Survey instead of returning to their editing session after account creation. My analysis on adding some logging to WelcomeSurveyHooks.php :
Edit Source (Working):

• returnToQuery: 'action=edit' ==> PRESERVED
• userWasEditing() result: true ==> DETECTION SUCCEEDS
• onCentralAuthPostLoginRedirect() user was editing -> preserving return parameters and exiting

Visual Editor (Failing):

• returnToQuery: ==> '' " PARAMETER LOST
• userWasEditing() result: false ==> DETECTION FAILS
• onCentralAuthPostLoginRedirect() user was NOT editing - proceeding to welcome survey redirect

Core MediaWiki
On LoginSignupSpecialPage.php on getPreservedParams() :

foreach ( $properties as $key => $prop ) {
    $value = $this->$prop;  // $this->mReturnToQuery = ""
    if ( $value !== '' ) {
        $params[$key] = $value;
    } else {
        unset( $params[$key] );  // VE parameters get unset here
    }
}

core seems to only preserve hardcoded core parameters but strips veaction parameter during the authentication flow. The parameter loss occurs before either hook executes, during the account creation process in LoginSignupSpecialPage::loadRequestParameters().

Specific Flow:

1. User edits: http://localhost:8080/w/index.php?title=%C5%A0molka&veaction=edit
2. Creates account: http://localhost:8080/w/index.php?title=Special:CreateAccount&returnto=%C5%A0molka
3. Core processing: strips veaction parameter
4. GrowthExperiments: receives empty returntoquery
5. Fails: user redirected to Welcome Survey

Would it make sense to propose a standardized way that lets us declare which parameters should persist across redirects? I’m happy to explore patch ideas if others think this is worth pursuing. cc, @Michael , @Sgs

Ohhh, good find!
It sounds like if the user is editing via VisualEditor from a logged out state and then creates an account before publishing, then the user flow (and associated redirects) are not working as intended.

Would it make sense to propose a standardized way that lets us declare which parameters should persist across redirects? I’m happy to explore patch ideas if others think this is worth pursuing.

Hopefully @Michael or @Sgs can help decide on how to track down and solve this. I'm not sure on the technical solution, but I can say that this task remains a high-priority for solving from my perspective. This bug has the potential to impact newcomer activation, which relates to our main WE1.1 (constructive edits for newer contributors).

Change #1172404 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Preserve other URL params during redirect CreateAccount → Userlogin?sul3-action=signup

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

Change #1172406 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Set 'returntoquery' on login/signup links when building edit intro messages

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

@Sgs raised this on Slack with the MediaWiki-Platform-Team. Part of the issue is definitely a bug in CentralAuth, this patch should fix it. Another part is a missing feature in VisualEditor, and that patch should fix that too (by luck, I was involved with that code too while on the Editing team). There may be more parts; there are many, many ways to reach the signup flow, and this task is somewhat unclear about which of them are not behaving right. I suggest getting these patches merged first, and then unleashing our QA folks on finding and documenting all the other possible flows.

On English Wikipedia I think you'll also have to fix the anoneditwarning message override which currently ignores $1 / $2.

Change #1172404 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Preserve URL params in CreateAccount → UserLogin?sul3-action redirect

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

Change #1172406 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Set 'returntoquery' on login/signup links when building edit intro messages

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

In T397193#11032979, @Tgr wrote:

On English Wikipedia I think you'll also have to fix the anoneditwarning message override which currently ignores $1 / $2.

Good point. So the message should be updated to something like:

[[File:AnonEditWarning.svg|10x20px|left|link=|alt=]]<div style="text-align: center;"><span style="color:#d33; font-weight:bold;">You are not logged in.</span> Your [[IP address]] will be publicly visible if you make any edits. If you <span class="plainlinks">'''[{{fullurl:Special:UserLogin|returnto=$1&returntoquery=$2} log in]''' or '''[{{fullurl:Special:CreateAccount|campaign=anoneditwarning&returnto=$1&returntoquery=$2}} create an account]'''</span>, your edits will be attributed to a username, among [[Wikipedia:Why create an account?|other benefits]].</div>

@Sdkb is this something you'd be comfortable updating in MediaWiki:Anoneditwarning, or making an on-wiki request? Alternatively a Growth engineer can also change it.

@Sgs, implemented! It looks like the code above was missing a closing bracket, which I added. If you see any other issues, please let me know right away.

In T397193#11093429, @Michael wrote:

Is our CI setup sufficiently close to production that we can create a meaningful automated test for this?

Not really. Most of production's auth logic (including SUL3, which caused this issue) is in MediaWiki-extensions-CentralAuth. Unfortunately, CentralAuth-related code is both mostly untested and mostly untestable, as CI does not use CentralAuth at all (except in CentralAuth's own tests). This is an intentional decision – we basically have two bad options to pick from:

1. Installing CentralAuth in CI: This would allow us to cover the authz mechanisms we actually use in production via automated CI-enforced tests. However, it would result in having the default authz mechanisms (provided by Core) mostly untestable. In other words, our automated tests could help us ensure our own production will not break, but it will cause random breakages in third-party MediaWiki installations.
2. Not installing CentralAuth in CI (status quo): This is almost a complete inverse of the first option – it allows us to test the default authz logic, but it makes it nearly impossible to test anything CentralAuth-related, particularly if we want to test integration between CentralAuth and some other extension.

While the status quo is still a bad option, it arguably puts us in a better state than the alternative (installing CI). This is because we tend to notice issues in our production relatively quickly: we update our installation every week (compare to the "every six months" release cycles for external wikis), we are by far the most used installation of MediaWiki and we have the densest concentration of MediaWiki experts. None of those applies for third parties, and relying on user reports (generally delayed by at least 6 months since the breaking patch) is much worse.

For more details on this, please see T321864 and T333541.

So, now that I outlined why a simplish test is not possible, what can we do? I see several options:

1. Support multiple versions of configurations in CI: This would allow us to run CI pipelines with both CentralAuth enabled and CentralAuth not enabled, which would mean we would no longer have to choose. It would also allow us to ensure that certain behaviour exists regardless of configuration, which is pretty much impossible to do in the present day.
2. Create an ad-hoc CI job just for one extension: In CI config, CI jobs for extensions usually come from predefined templates. However, in principle, it should be possible to create a job specific for a given repository. In theory, we should be able to create a job that would run (for example) GrowthExperiments' tests with CentralAuth enabled, allowing us to write a full integration test for this.
3. Run out-of-CI tests regularly against live wikis: We can run some tests outside of the regular CI pipelines, hitting production (presumably, testwiki) or beta directly, rather than a fresh MW instance as CI does currently. This would help us to notice issues that are hard to test for directly. There would be a slight delay (if the test runs daily, we would notice the issue at most the day after it occurred), but it would be simpler to do (for Growth anyway) than changing how CI itself behaves. For what it is worth, Pywikibot took this approach (see https://test.wikipedia.org/wiki/User:Pywikibot-test for related info; GitHub Workflow specifications are available as well) .
4. Test individual subfeatures and not the full integration: If we determine it is not viable to simulate the actual breakage within a CU-executed test, we can attempt to break it into components. For example, it should be trivial to test that CentralAuth passes certain parameters over when redirecting users to auth.wikimedia.org. Similarly, it should be possible to ensure that VisualEditor sets the parameter on the first URL.

None of those options is a perfect one, and all of them have significant tradeoffs. Here is a quick summary of them:

1. Support multiple versions of configurations in CI: In terms of benefits, this is the clear winner. However, it would require significant investments in the CI pipeline, and it is not something we can do currently. It is extremely likely to break a ton of tests, including both actual failures (that we did not notice) and behaviours that are not necessary in certain cases (for example, we expect most of core's auth logic to do nothing if CentralAuth is present). It would have to be a long-term project, not something an engineer or two can carry out in their spare time.
2. Create an ad-hoc CI job just for one extension: Assuming we can create a pipeline that would fulfil our needs in terms of enabled extensions, we would need to convince RelEng to add an ad hoc bit to an otherwise standardized set of pipelines. This is likely to cause issues each time a CI upgrade is made, and it would make GrowthExperiments a very special extension from a CI perspective in general, which is likely not warranted. Wikibase is a present-day example of this (given the Wikibase repository contains more than one extension), and the troubles associated with the setup there is the primary reason why we have CommunityConfiguration and CommunityConfigurationExample as fully separate extensions (in fact, CI admin docs do explicitly mention to check CI works on both core and Wikibase when doing upgrades). While this solution would allow us to solve what we need to, I think it would be declined by RelEng (and probably rightfully so).
3. Run out-of-CI tests regularly against live wikis: This is likely the simplest solution for the Growth team that would give us a full integration test. It would require us hosting the special tests somewhere and maintaining the infrastructure for them (not only the tests themselves, but also the how-to-run scripts/config files). GitLab allows us to get a repo with CI enabled relatively simply, but I'm not sure we want to maintain such pipeline in the longer run. The biggest problem is that this would either only detect issues (shortly) before deployment (on testwiki in the earliest case), or suffer from fairly frequent outages in Beta.
4. Test individual subfeatures and not the full integration: I'm afraid this is the best we can do given our current infrastructure. On the plus side, it would detect if this issue was to happen because of the exact same cause. On the negative said, it wouldn't catch if the same regression happened for a different reason, which is something we want to know about as well.

I just got confused for the second time about seeing an Incoming task with a patch merged, and I split the test-writing into T402719: Write an automated test to ensure users creating a new account from the editor are redirected back to the editor, not to Welcome survey. Transferring my comment from above there, and we can consider the discussion there.

I re-tested this issue in testwiki wmf.10 and I can reproduce it again. I also tested it enwiki wmf.7, and there, the WS is not shown, and the user is redirected to the editing article. Probably this is a different regression somwhere between wmf.7-10 with the same outcome. @Etonkovidova could you confirm it?

Unrelated relatedly I also tested the so called "mid edit sign up" on desktop in enwiki wmf.7, doing some edits on the editor before clicking on the log in link and I didn't get the changes on the editor when redirected to it. Probably no related to the prior issue but worth looking into it. @Etonkovidova is this also your observation?

In T397193#11500506, @Sgs wrote:

I re-tested this issue in testwiki wmf.10 and I can reproduce it again. I also tested it enwiki wmf.7, and there, the WS is not shown, and the user is redirected to the editing article. Probably this is a different regression somwhere between wmf.7-10 with the same outcome. @Etonkovidova could you confirm it?

I observed the identical and correct behavior for both wmf.10 and wmf.7.
(1) creating account after starting editing in VE on testwiki wmf.10

• anon user in VE sees the popup with the warning and clicks the link to create an account
• a user is redirected to Special:CreateAccount (in a different tab)

https://auth.wikimedia.org/testwiki/wiki/Special:CreateAccount?useformat=desktop&usesul3=1&returnto=Mavetuna&returntoquery=veaction%3Dedit&centralauthLoginToken=d04a8a861575b8ce387e83b64d166797

• a user creates an account and is redirected back to their mid-edit state (with redundant display of the popup "Welcome to Wikipedia", but it's super minor):

No Welcome Survey is displayed

(2) creating account after starting editing in VE on enwiki wmf.7`

• anon user in VE sees the popup with the warning and clicks the link to create an account
• a user is redirected to Special:CreateAccount (in a different tab)

https://auth.wikimedia.org/enwiki/wiki/Special:CreateAccount?useformat=desktop&usesul3=1&returnto=Paul_Sadala&returntoquery=veaction%3Dedit&centralauthLoginToken=2d6b81fcababa3caf919dcc507e13ec1

(3) Also, just in case, checked that Special:WelcomeSurvey is present for users who create an account directly from Special:CreatAccount page

Note: It's quite possible that there are some edge cases that probably would worth to check that might result in the behavior that you saw on testwiki wmf.10, e.g.

• creating an account on mobile
• in VE popup click to open the Create account link in a different tab
• copy the Create account link to a different browser

Unrelated relatedly I also tested the so called "mid edit sign up" on desktop in enwiki wmf.7, doing some edits on the editor before clicking on the log in link and I didn't get the changes on the editor when redirected to it. Probably no related to the prior issue but worth looking into it. @Etonkovidova is this also your observation?

That scenario gives some ambiguity and, potentially, confusion and loss of typed content. Upon proceeding and creating an account, a user has two tabs - one tab with VE and not-yet-saved edits (that anon user made), another tab shows a newly created account looged in, and VE doesn't display the typed edits.

The steps

• as anon user clicks on Edit, the warning appears prompting to create an account
• an anon user ignores the warning and types some text
• then, an anon user decides to create an account and clicks to see the warning again (the triangle button)
• clicks on Create account link, the new tab displays Special:CreateAccount page
• a user creates an account, and is returned to page in editing mode (VE) without their edits displayed

Now, a new user should figure out that in the first tab the edits are displayed and can be published.

I'm not sure we tested the same flow, for (1) and (2) I was referring to the original steps to replicate from this issue description, which I assume are on mobile. Here's a video of what I'm observing.

In T397193#11502926, @Sgs wrote:

I'm not sure we tested the same flow, for (1) and (2) I was referring to the original steps to replicate from this issue description, which I assume are on mobile. Here's a video of what I'm observing.

I tested this as well. On the first attempt, it correctly redirected to the page the user was editing. However, subsequent edits redirected to the welcome survey instead. I'm not sure why that behavior changed.