Some notes on UX and implementation options:

Status quo

• Doing the login process in a separate popup window is common and nice (cf T71596: Provide JavaScript login widget), but normally that window would close after a successful login. Returning to the edited page instead seems confusing. The user might open the page for editing again and end up with two open editors for the same page, accidentally self-revert or edit conflict, etc.
• The original window still shows the user as logged out and still warns about the IP becoming visible (which is not actually true at this point). This also limits the user's options (e.g. the checkbox for marking the edit as minor or adding to the watchlist is not present.)
• Login-page logic using returntoquery to detect that the user is in the middle of an edit does not work (we ran into this problem in T310320: Account creation + Growth tools: improve UX for newcomers who create an account while mid-edit, although there are probably other ways to work around it).

No popup

Just do what the core editor does: do not add target=_blank, suppress the "Your changes might not be saved" warning, let the user navigate away for the login/signup process, add returntoquery so the user will end up back in the editor. This is easy but has some drawbacks:

• Inconsistent with how other VE edit notice links work.
• Unsaved changes to the article will be preserved, but this is not obvious to the user.
• The warning about the user not being logged in still shows up. (Does that get stashed alongside the modified article text?)

Close the popup after login and try to update the original page

Close the popup after successful login/signup. The easiest way to do this is to create a new special page such as Special:FinishLogin and have that page output window.close(), and send the user to it via returnto. Since only programmatically opened windows can be closed programmatically, replace target=_blank in the VE notice with a click handler that calls window.open(). Before closing, fire some hook via window.opener so the original page can react to being logged in (either by reloading, or by doing some kind of live refresh - in the case of CentralAuth this conveniently already exists). The same behavior could also be applied to the core editor.

• The CentralAuth UI refresh only changes the user toolbar which is confusing (e.g. still no minor edit checkbox). Doing a full page refresh looks better, not sure if there is any risk of lost state. It would probably have the same issue as the no-popup option with anoneditwarning being preserved.

In T318142#8247544, @kostajh wrote:

Marking as high priority as it is needed to complete T310320: Account creation + Growth tools: improve UX for newcomers who create an account while mid-edit.

Can the prio be set lower since it seems T310320 is resolved without this, and it seems to be an very minor edge case?

Note in the video F35649585 I added to the description, it's only the VE create account prompt that leads to this scenario, but that is dismissed before the user makes any edits in VE.
All other "Create account" CTAs (e.g., the one in the page tools area) brings up a non-problematic browser dialog.

It seems to me that is would be an extremely rare and unusual case that someone would firstly dismiss the VE create account prompt, makes edits, then clicks on the "" alert icon to bring up the prompt again to create an account in tab 2 and then come back to tab 1 to publish without wanting the edit to be saved to this account. As such, I wonder if the 'fix' here could be simply to make the warning message and buttons better labeled in the rare cases it is encountered?

Current:	Proposed

Another minor change would be to exit out of the "Save your changes" confirmation dialog if the user selects the Dismiss/Cancel button in the warning dialog.

In T318142#8354913, @KStoller-WMF wrote:

Lowering priority, but others should feel free to chime in if @RHo or I are missing something that makes this more urgent.

My understanding is that we haven't completely fulfilled the goals of T310320, since the user is sent to the WelcomeSurvey after creating an account while editing an article in VE, and the goal of T310320 was to bypass the WelcomeSurvey.

In T318142#8386875, @kostajh wrote:

In T318142#8354913, @KStoller-WMF wrote:

Lowering priority, but others should feel free to chime in if @RHo or I are missing something that makes this more urgent.

My understanding is that we haven't completely fulfilled the goals of T310320, since the user is sent to the WelcomeSurvey after creating an account while editing an article in VE, and the goal of T310320 was to bypass the WelcomeSurvey.

Ah gotcha, so does that mean this task is more about fixing that 2nd tab flow (create account --> Logged in edit in progress) and not worry about expired session happening in tab 1? And in that case is the only issue that the user will not have whatever they started editing in the logged in tab #2 state?
If so, I think it's fine to update it so that post-create account they go to the article mid-edit in the second tab but it doesn't bring over unsaved edits in tab 1, since this seems a very unlikely scenario. Does that sound OK?

In T318142#8387302, @RHo wrote:

In T318142#8386875, @kostajh wrote:

In T318142#8354913, @KStoller-WMF wrote:

Lowering priority, but others should feel free to chime in if @RHo or I are missing something that makes this more urgent.

My understanding is that we haven't completely fulfilled the goals of T310320, since the user is sent to the WelcomeSurvey after creating an account while editing an article in VE, and the goal of T310320 was to bypass the WelcomeSurvey.

Ah gotcha, so does that mean this task is more about fixing that 2nd tab flow (create account --> Logged in edit in progress) and not worry about expired session happening in tab 1? And in that case is the only issue that the user will not have whatever they started editing in the logged in tab #2 state?
If so, I think it's fine to update it so that post-create account they go to the article mid-edit in the second tab but it doesn't bring over unsaved edits in tab 1, since this seems a very unlikely scenario. Does that sound OK?

I think it's a bit more severe than that, though I might be misunderstanding. The existing behavior for anonymous users in VE:

• See the warning that you're logged out and press create account

• That opens a new tab with Special:CreateAccount
• You create the account, then you're on WelcomeSurvey. I would expect that you are instead redirected to the article were on when you first clicked Edit.
• The previous tab appears to show you as logged-out.

I think what we should do is implement the change proposed by @Tgr in the description of this task:

• clicking on "Create an account" or "log in" in the VisualEditor warning should open a pop up, with a bare bones account creation / login screen (T317595, T71596)
• User logs in or creates account, when that window closes, reload the VE page, any changes the user has made will be automatically recovered, and the user will see that they're logged-in.

That type of login/account creation workflow would probably be welcomed by other teams/developers as well.

In T318142#8421527, @kostajh wrote:

In T318142#8387302, @RHo wrote:

In T318142#8386875, @kostajh wrote:

In T318142#8354913, @KStoller-WMF wrote:

Lowering priority, but others should feel free to chime in if @RHo or I are missing something that makes this more urgent.

My understanding is that we haven't completely fulfilled the goals of T310320, since the user is sent to the WelcomeSurvey after creating an account while editing an article in VE, and the goal of T310320 was to bypass the WelcomeSurvey.

Ah gotcha, so does that mean this task is more about fixing that 2nd tab flow (create account --> Logged in edit in progress) and not worry about expired session happening in tab 1? And in that case is the only issue that the user will not have whatever they started editing in the logged in tab #2 state?
If so, I think it's fine to update it so that post-create account they go to the article mid-edit in the second tab but it doesn't bring over unsaved edits in tab 1, since this seems a very unlikely scenario. Does that sound OK?

I think it's a bit more severe than that, though I might be misunderstanding. The existing behavior for anonymous users in VE:

• See the warning that you're logged out and press create account

• That opens a new tab with Special:CreateAccount
• You create the account, then you're on WelcomeSurvey. I would expect that you are instead redirected to the article were on when you first clicked Edit.
• The previous tab appears to show you as logged-out.

I think what we should do is implement the change proposed by @Tgr in the description of this task:

• clicking on "Create an account" or "log in" in the VisualEditor warning should open a pop up, with a bare bones account creation / login screen (T317595, T71596)
• User logs in or creates account, when that window closes, reload the VE page, any changes the user has made will be automatically recovered, and the user will see that they're logged-in.

That type of login/account creation workflow would probably be welcomed by other teams/developers as well.

Yes, that description matches my understanding. However, I was under the impression that @Tgr's proposal to have an account pop-up would be a much larger undertaking, so the short term interim fix would be to re-direct people in the new tab who have created an account edit their page (instead of going to the welcome survey), since they will have been unlikely to have made any edits in the 1st tab. That first tab becomes a dead end which is fine for the time being until the longer term pop-up login is created.

I agree with @kostajh that this is a pretty significant UX issue and we should do one of the options presented in T318142#8248605 (neither of which would create a dead-end in the sense of the user losing or being unable to save their changes) soonish. I don't think either option is a prohibitive amount of effort; the VE engineers I asked weren't convinced about the popup being the better UX option, though. Maybe we should implement both options so a designer or QA person can try them out andcompare them.

In T318142#8426042, @Tgr wrote:

I agree with @kostajh that this is a pretty significant UX issue and we should do one of the options presented in T318142#8248605 (neither of which would create a dead-end in the sense of the user losing or being unable to save their changes) soonish. I don't think either option is a prohibitive amount of effort; the VE engineers I asked weren't convinced about the popup being the better UX option, though. Maybe we should implement both options so a designer or QA person can try them out andcompare them.

I guess my main quibble is whether it is a significant UX issue, if we were to do the bare minimum change the new login tab to redirect to the mid-edit article with the user logged in (instead of going to welcome survey). It seems it would be an edge case for someone who proceeds from unregistered --> registered in new window/tab would then go back to first tab to continue editing with the expired unregistered session. Note that once the person continues to edit while unregistered they will not see this create account prompt again unless they click on the warning icon in the header, so it is very unlikely occurrence that any edits would occur on an expired page.

Having said that, if it is not such a big effort to do one of the options in T318142#8248605, the close pop-up option seems preferable if by "pop-up" we mean a modal dialog opening over the editing tab (see mock below). And in that case, as mentioned, the forced page refresh after login would be fine because it's unlikely any edits would have occurred prior to account creation.

1. Log in/Create account prompt on editor loading

2. Create account modal dialog

3. Page refreshed with new account logged in

In T318142#8426406, @RHo wrote:

Note that once the person continues to edit while unregistered they will not see this create account prompt again unless they click on the warning icon in the header, so it is very unlikely occurrence that any edits would occur on an expired page.

That's a good point, I didn't consider that. In light of it I agree it's not a significant issue (beyond suppressing the welcome survey).

Having said that, if it is not such a big effort to do one of the options in T318142#8248605, the close pop-up option seems preferable if by "pop-up" we mean a modal dialog opening over the editing tab (see mock below).

I think neither is a big effort. It would have to be a real popup though, not a modal. Reimplementing the login form in a modal would be a ton of effort, would duplicate security-sensitive code, it would place the login form in a looser security context (user and site scripts are disallowed on the login page), and it would interfere with the CentralAuth cross-wiki login behavior which is based on doing invisible redirects after submitting the login form. Maybe an iframe wrapped in a modal would work, but I'm not confident (see the last paragraph of T317595#8281870).
And in that case, as mentioned, the forced page refresh after login would be fine because it's unlikely any edits would have occurred prior to account creation.

1. Log in/Create account prompt on editor loading	2. Create account modal dialog	3. Page refreshed with new account logged in

In T318142#8426960, @Tgr wrote:

In T318142#8426406, @RHo wrote:

Note that once the person continues to edit while unregistered they will not see this create account prompt again unless they click on the warning icon in the header, so it is very unlikely occurrence that any edits would occur on an expired page.

That's a good point, I didn't consider that. In light of it I agree it's not a significant issue (beyond suppressing the welcome survey).

Having said that, if it is not such a big effort to do one of the options in T318142#8248605, the close pop-up option seems preferable if by "pop-up" we mean a modal dialog opening over the editing tab (see mock below).

I think neither is a big effort. It would have to be a real popup though, not a modal. Reimplementing the login form in a modal would be a ton of effort, would duplicate security-sensitive code, it would place the login form in a looser security context (user and site scripts are disallowed on the login page), and it would interfere with the CentralAuth cross-wiki login behavior which is based on doing invisible redirects after submitting the login form. Maybe an iframe wrapped in a modal would work, but I'm not confident (see the last paragraph of T317595#8281870).
And in that case, as mentioned, the forced page refresh after login would be fine because it's unlikely any edits would have occurred prior to account creation.

1. Log in/Create account prompt on editor loading	2. Create account modal dialog	3. Page refreshed with new account logged in

Ah I see, this makes me lean towards opening in the same window if it can't be a modal, though could we try your suggestion to trial both popup and open in window option to compare which seems better?

This has been sitting for over a month, so I'm moving it out of the current sprint.
I agree an improvement would be nice, but perhaps this is enough of an edge case we don't need to worry about right now?