Echo does something similar where it starts loading OOUI after the click. There might need to be some interim loading state that is currently missing in the design.

@STran here's the IPBee investigate that I mentioned in our 1:1 yesterday.

This is a lot of questions but I'll work my way through the list. If someone is looking for investigation work, I'm currently investigating the OOUI components and these questions could be worked on in parallel:

• Would it be possible to accommodate a captcha in the modal from a technical pov? The captcha shows up on Special:CreateAccount sometimes (not sure what triggers it).
• Would it be possible to redirect them to the article's edit page after they've logged in or created their account?
• Is it possible to do this just on Desktop and have a different workflow for mobile?

Is it possible to load an OOUI modal from an article page?

Yes. OOUI is loaded and you can generate boilerplate dialogs (OOUI's name for a modal) without loading any additional resources. However, we'd have to extend and write our own modal so we'll have to load some custom JS.

Is it possible to have the Create account form be put in and run from a modal? Any security implications?

Technically, yes if you want to use Special:CreateAccount as it exists. I can think of two solutions and neither are great imo:

1. iframe Special:CreateAccount - The wikis are sensibly set to reject all iframes (to prevent clickjacking). We'd have to set something like $wgEditPageFrameOptions = "SAMEORIGIN"; which would decrease security. On top of that, we'd have to do some work to only load the content as opposed to an entire page. I do not recommend this solution however, it is possible.
2. try to use the existing create account form's PHP - It...should be possible? Maybe? it's janky if anything. We would have to write the form in JS and POST it, since I don't think this is expected to be loaded until the user interacts with the "edit" button. I also don't like this since it sounds like we'd just be reinventing the wheel and in any case it's better to use what's already there since it's already solved the auth/security problems.

Alternatively, we can write our own create account form. The API allows for programmatic creation of accounts via createaccount. We could probably make this work.

Is it possible to have the Login form be put in and run from a modal? Any security implications?

The same as above. The API allows for clientlogin which we could probably use. I don't know if it's a good idea to try to avoid reloading the page after a token is acquired per the figma mock. It sounds like a lot of spaghetti jQuery.

Would it be possible to accommodate a captcha in the modal from a technical pov? The captcha shows up on Special:CreateAccount sometimes (not sure what triggers it).

Probably if we have control over the form. The extension that provides captcha is ConfirmEdit and it defines the form field HTMLFancyCaptchaField that can probably be used. I'd have to do more research to confirm.

Would it be possible to redirect them to the article's edit page after they've logged in or created their account?

Yes if we use Special:CreateAccount or Special:UserLogin, probably if we use the API. Special:CreateAccount and Special:UserLogin take a parameter, returnto which handles the redirect. The API actions take the parameters createreturnurl and loginreturnurl respectively but I don't know how these work in practice.

Is it possible to do this just on Desktop and have a different workflow for mobile?

Should be. The JS is aware if the user is on the mobile or desktop experience so we should just not load or load something else for mobile.

As an alternative (that you may have considered; I apologize but cannot find the user research atm), maybe we could get away with a simple dialog that explains the situation and asks users to create an account/log in with the buttons allowing the user to navigate to the create account or login page with the relevant returnto parameter. They would then understand why they were taken to a different page with the expectation of being redirected back.

@STran Thanks for the investigate! Comments inline:

In T317595#8250370, @STran wrote:

Is it possible to load an OOUI modal from an article page?

Yes. OOUI is loaded and you can generate boilerplate dialogs (OOUI's name for a modal) without loading any additional resources. However, we'd have to extend and write our own modal so we'll have to load some custom JS.

Is it possible to have the Create account form be put in and run from a modal? Any security implications?

Technically, yes if you want to use Special:CreateAccount as it exists. I can think of two solutions and neither are great imo:

1. iframe Special:CreateAccount - The wikis are sensibly set to reject all iframes (to prevent clickjacking). We'd have to set something like $wgEditPageFrameOptions = "SAMEORIGIN"; which would decrease security. On top of that, we'd have to do some work to only load the content as opposed to an entire page. I do not recommend this solution however, it is possible.
2. try to use the existing create account form's PHP - It...should be possible? Maybe? it's janky if anything. We would have to write the form in JS and POST it, since I don't think this is expected to be loaded until the user interacts with the "edit" button. I also don't like this since it sounds like we'd just be reinventing the wheel and in any case it's better to use what's already there since it's already solved the auth/security problems.

Alternatively, we can write our own create account form. The API allows for programmatic creation of accounts via createaccount. We could probably make this work.

Is the recommendation here to write our own form given that options 1 and 2 sound problematic?
Are there any concerns with writing our own form?

Is it possible to have the Login form be put in and run from a modal? Any security implications?

The same as above. The API allows for clientlogin which we could probably use. I don't know if it's a good idea to try to avoid reloading the page after a token is acquired per the figma mock. It sounds like a lot of spaghetti jQuery.

Are you saying it's technically easier to reload the page after the user has logged in successfully and then land them on the editor? If so, that sounds acceptable to me.

Would it be possible to accommodate a captcha in the modal from a technical pov? The captcha shows up on Special:CreateAccount sometimes (not sure what triggers it).

Probably if we have control over the form. The extension that provides captcha is ConfirmEdit and it defines the form field HTMLFancyCaptchaField that can probably be used. I'd have to do more research to confirm.

Would it be possible to redirect them to the article's edit page after they've logged in or created their account?

Yes if we use Special:CreateAccount or Special:UserLogin, probably if we use the API. Special:CreateAccount and Special:UserLogin take a parameter, returnto which handles the redirect. The API actions take the parameters createreturnurl and loginreturnurl respectively but I don't know how these work in practice.

Is it possible to do this just on Desktop and have a different workflow for mobile?

Should be. The JS is aware if the user is on the mobile or desktop experience so we should just not load or load something else for mobile.

---

As an alternative (that you may have considered; I apologize but cannot find the user research atm), maybe we could get away with a simple dialog that explains the situation and asks users to create an account/log in with the buttons allowing the user to navigate to the create account or login page with the relevant returnto parameter. They would then understand why they were taken to a different page with the expectation of being redirected back.

Our team hasn't done a lot of user research around this apart from the user tests that Prateek ran that I will let him talk about.
Prateek and I talked to the Growth team (Marshall and Kirsten) who have been working in this space for a while. They shared links to their project where this is relevant (Understanding first day) and prior research about account creation contexts. According to them, a modal with the sign up form would be the most effective solution and hence we chose to go with that option.

Is the recommendation here to write our own form given that options 1 and 2 sound problematic?

I'm not a strong yes (because I need to look more into the API call) but it seems like the least problematic methodology and the one least likely to generate a bunch of weird bugs we only find out after we've committed. Given that this is being executed via JS, it's hard to argue for trying to make the PHP (which wasn't built with this use case in mind) work.

Are there any concerns with writing our own form?

Usually, whatever's there has a bunch of solved unknowns baked into it. If we want to move forward with (somewhat) reinventing the wheel, we should try to figure out what concerns were resolved by the form/pathway that already exists and make sure they're covered as well. I think we should also make sure we haven't created an avenue for abuse (eg. someone uses the form to spam create accounts for whatever reason) but I'm hoping that the API or the PHP form, whichever we go with, will deal with that for us.

If we do recreate the form, we probably should implement captcha and I don't think ConfirmEdit is set up to be extended. Some additional research would have to be done here for implementation.

Are you saying it's technically easier to reload the page after the user has logged in successfully and then land them on the editor? If so, that sounds acceptable to me.

Yes. The form will ideally redirect them to the edit page after they've created an account/logged in. I believe this is possible but I would need to look into the API more to confirm. I know that the PHP forms can and do redirect users.

cc @Tchanders for a second opinion. This is my opinion to the best of my knowledge, but perhaps you may have some additional context? 🙇

@STran thanks for the explanation. If it helps with the decision - I'm okay with us going slow on the project and taking the time to make sure we don't leave a trail of bugs.

I don't know if it's a good idea to try to avoid reloading the page after a token is acquired per the figma mock.

Are you referring to the part of the mock where after clicking Create your account it loads VE? If so, yep, totally okay to reload the page and then take to VE (or any editor).

As an alternative (that you may have considered; I apologize but cannot find the user research atm), maybe we could get away with a simple dialog that explains the situation and asks users to create an account/log in with the buttons allowing the user to navigate to the create account or login page with the relevant returnto parameter. They would then understand why they were taken to a different page with the expectation of being redirected back.

You can see the summary of the usability tests in this document (scroll to the bottom) and the specifics for each prototype in this sheet (see multiple sheets/prototypes at the bottom).

We didn't try the exact thing you're suggesting, but something close where they're taken to a disabled editor with a dialog that explains the situation and links to the create account form/modal. The understanding of what is going on was similar across all prototypes (including the fact that they're being returned to the page to edit it).

The reason why I recommended this approach was that it had the least friction. We explain why this is happening (the yellow notice) and let them do the next action (sign-up) in the same step (the modal). Also, as Niharika mentioned Growth have been thinking about this option too.

Noting that the returnto is important to keep the users in the flow that they've started.

cc @Tchanders for a second opinion. This is my opinion to the best of my knowledge, but perhaps you may have some additional context? 🙇

@STran and I had as chat about this investigation, and I'll add a few more things that we discussed...

• Is it possible to have the Create account form be put in and run from a modal? Any security implications?
• Is it possible to have the Login form be put in and run from a modal? Any security implications?

There are security implications here.

I think these questions came from some concerns that @Esanders raised in a meeting with @Prtksxna about previous attempts to create a login modal. It's an idea that has been discussed over the years, but never moved forward due to security concerns with asking for sensitive input over a modal. Some of the concerns are discussed on this ticket: T71596: Provide JavaScript login widget.

We can look into the problem again, but we'd need to tread carefully and get advice from others working on similar problems, e.g. T208823: Support asynchronous reauthentication.

Prateek and I talked to the Growth team (Marshall and Kirsten) who have been working in this space for a while. They shared links to their project where this is relevant (Understanding first day) and prior research about account creation contexts. According to them, a modal with the sign up form would be the most effective solution and hence we chose to go with that option.

Growth are working in a similar area, e.g. T318142: Account creation + Growth tools: Improve UX for desktop VisualEditor, and their planned solution involves navigating away from the page for login/account creation.

We should probably talk to them and find out:

• their perspective on login/account creation in a modal, since presumably they have discussed it too given their design research results
• whether the IPBEE work should be in the same place as any of the work they are doing

As an alternative (that you may have considered; I apologize but cannot find the user research atm), maybe we could get away with a simple dialog that explains the situation and asks users to create an account/log in with the buttons allowing the user to navigate to the create account or login page with the relevant returnto parameter. They would then understand why they were taken to a different page with the expectation of being redirected back.

This seems to me like a great idea for a first iteration: it could probably be done relatively quickly and solves the problem of notifying users who are logged out that they need to log in to edit. It would also provide a lot of the UI wiring while the security investigations are ongoing. And if the login modal proves untenable (as it has before), we'd still have made a big improvement.

We discussed following up this task with:

• making tasks for implementing the modal that links out to the login and account creation pages
• further investigations for having the form in the modal (where @STran has identified the need, above) - with the caveat that the security concerns might be too much to overcome

@Niharika @Prtksxna How does that sound?

We talked about this in a meeting and discussed having the proposed alternative:

As an alternative (that you may have considered; I apologize but cannot find the user research atm), maybe we could get away with a simple dialog that explains the situation and asks users to create an account/log in with the buttons allowing the user to navigate to the create account or login page with the relevant returnto parameter. They would then understand why they were taken to a different page with the expectation of being redirected back.

as an internal MVP while we work towards building the CreateAccount and Login form into the modal. That work is contingent on the findings from our conversations with Growth, Security, Performance. If building the forms in the modal does not seem feasible we will fall back on this alternative.

@STran @Tchanders If the above sounds good can we create follow up tasks and close this ticket?

Yes I'll write up the tasks. Moving this investigation back into in-progress to reflect that.

I can think of three approaches:

• Just show a dialog with a login link and returnto/returntoquery set. This is simple to do, and in this specific use case (you are showing the call to action when the user tries to edit but hasn't started editing yet) it seems to me like a fine solution. If the user is in the middle of editing (possible if they weren't blocked yet when they started editing and encounter the block when trying to save, but an unlikely edge case) and might not want to lose changes, it would be more problematic.
• Construct your own dialog in Javascript, using the clientlogin and createaccount APIs. (I don't think the security concerns are convincing, for reasons which have already been described in T71596.) This was never done before so I'd expect surprises and potentially improvements needed to the APIs. It should be done eventually, and the APIs have been written with exactly this use case in mind, so it would be a worthwhile improvement to MediaWiki core, although an overkill for your use case IMO. The APIs return an abstract form definition, the client code would have to turn that into an actual form inside the modal. In theory this would cover captchas, 2FA and any number of other workflows that can be part of the login or signup workflow, depending on what extensions are installed - you would just get the definition of the form field, without having to know what kind of information workflow step is happening. In practice, as I said, no one has done this before, so I'd expect to hit usability and maybe functionality problems (which should be fixed, but make this a larger effort than it first sounds). One thing I can think of right off the bat is that the CentralAuth cross-wiki login sequence is not covered by any API.
• Open the login page in a separate page (a popup window or a new tab), then somehow notify the original page that the login was successful, and refresh it. T318142: Account creation + Growth tools: Improve UX for desktop VisualEditor discusses this in more detail, although chances are that we'll take the simpler "no popup" approach mentioned there. I think it should be doable fairly easily in a somewhat hacky way.

I don't think there is a good reason to build a new login form special page (if the difference is just not showing the skin, that can be done in the existing special page as an URL option, and duplicating such a security-sensitive class shouldn't be taken lightly), and I'm not sure an iframe would be viable (site scripts and gadgets are disallowed on the login page to make credentials theft via malicious site scripts at least slightly harder, you'd have to sandbox the iframe to preserve that, which might cause usability issues; clickjacking would still be a concern even if it's sandboxed; and there is a chance that in an iframe the CentralAuth post-login redirect sequence would trigger anti-tracking safeguards in the browser that it doesn't trigger now).

Thanks for commenting everyone! I've created the tickets and am now closing this investigation out. If I've missed anything, please feel free to re-open or create new tickets.

T319501: Investigate: Does IPBEE live in core or an extension
T319504: Show a dialog on the article page when an anonymous user tries to make an edit
T319508: Investigate: How the API can be used to create accounts and log in
T319509: Investigate: How would CentralAuth interact with IPBEE
T319510: Stub out an extension of dialogs that allows for a form as its content
T319511: Implement the IPBEE login form

Since you're looking at this in the context of the Edit button, it would also be nice if a modal could be triggered from clicking the Special:Login link in the top right that shows up while logged out. (cc @ovasileva from Discord this afternoon)

Which I guess is already-linked T71596: Provide JavaScript login widget.

One other thing I'd think about is our (English Wikipedia's) current warning on the Special:CreateAccount page which is "Consider using a username other than your real name, as usernames are public and cannot be made private later."

We have deprioritized this work because of changing priorities. Leaving this task open if/when this work gets picked up again.