Change Details

**Description** What currently happens: 1. Logged-out user is editing article in VE on desktop, clicks "Create account" prompt from VE 1. That opens a new tab; user fills out account creation form, and then is prompted to go to WelcomeSurvey. 1. WelcomeSurvey offers to take user back to the article they were editing Tab 1 has the article with any unsaved changes the user may have already made; Tab 2 has the article in View mode. If the user goes to Tab 1 and presses save, VE will tell them that they're now logged-in, and that their changes will be associated with the logged-in user if they proceed. If they press "Try again", the edit is associated with the new user. >>! In T310320#8245693, @Tgr wrote: > To recap the relevant part of the gerrit discussion: > * VE omits the `returntoquery` parameter that the same "log in or register if you don't want your IP address published" (`anoneditwarning`) notice does use in core. This means it won't return to the editor after going through the signup process. Since we are triggering welcome survey skipping based on whether the user is going to return to editing, the survey won't be skipped. This might be an oversight on VE's part; when the logic was added in [[https://gerrit.wikimedia.org/r/q/Ia28f59a341e1a04b4d143abbfe5c63e4a420056f|Ia28f59a341e1a04b4d143abbfe5c63e4a420056f]], it matched the core logic which also didn't have `returntoquery`, and then VE did not get updated when core was. Easy to fix, I'm not sure how useful it would be though since... > * VE adds target=_blank to the links in the notices, forcing them to open in a new window. This is an understandable choice, even though in theory the editor would recover the contents if you navigate away and then return, but that still seems disruptive. But then, returning to the same page in the new window seems more confusing than useful. Opening the editor in the new window would be even more so. Typically, if you log in in a popup, that popup should close when you are finished. > * The VE UX stays logged out if you log in in a separate window, and still shows the `anoneditwarning` warning, even though the edit will not actually be anonymous if you save it. (This comes with all kinds if side issues, e.g. the save options are different for an anonymous and a logged-in user, such as the "minor" flag or the watchlist options not being available for anons.) This is obviously bad but not easy to fix - the old wikitext editor can be refreshed by doing a preview, but I don't think VE has anything similar. > > Maybe what could be done is: > * make `returnto` point to something like Special:FinishLogin when the link opens in a new window; > * make Special:FinishLogin close the current window; > * before doing that, have it call back to the parent window and trigger an autologin attemept, which will at least refresh the user menu on CentralAuth wikis, although it won't do anything useful in vanilla MediaWiki. > * As a stretch goal, maybe add target=_blank to the wikitext editor as well, and have the JS callback do a preview in that case. **Acceptance Criteria** # Should be able to .... # .... #### Completion checklist **Functionality** [] The patches have been code reviewed and merged [] The task passes its acceptance criteria **Engineering** [] There are existing and passing unit/integration tests [] Tests for every involved patch should pass [] Coverage for every involved project should have improved or stayed the same **Design & QA** [] If the task is UX/Design related: it must be reviewed and approved by the UX/Design team [] Must be reviewed and approved by Quality Assurance. **Documentation** [] Related and updated documentation done where necessary - Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc) - Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments | Extension:GrowthExperiments ]] or [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation | Extension:GrowthExperiments/Technical documentation ]] pages.

**Description** What currently happens: # Logged-out user is editing article in VE on desktop, clicks "Create account" prompt from VE # That opens a new tab; user fills out account creation form, and then is prompted to go to WelcomeSurvey. # WelcomeSurvey offers to take user back to the article they were editing Tab 1 has the article with any unsaved changes the user may have already made; Tab 2 has the article in View mode. Scenario 1: If the user goes to Tab 1 and presses save, VE will tell them that they're now logged-in, and that their changes will be associated with the logged-in user if they proceed. * If they press "Try again", the edit is associated with the new user account created. * If they press "Dismiss", they return to the confirmation dialog then press "Publish", the edit proceeds, again associated with the new user account created. Video of scenario: {F35649585} >>! In T310320#8245693, @Tgr wrote: > To recap the relevant part of the gerrit discussion: > * VE omits the `returntoquery` parameter that the same "log in or register if you don't want your IP address published" (`anoneditwarning`) notice does use in core. This means it won't return to the editor after going through the signup process. Since we are triggering welcome survey skipping based on whether the user is going to return to editing, the survey won't be skipped. This might be an oversight on VE's part; when the logic was added in [[https://gerrit.wikimedia.org/r/q/Ia28f59a341e1a04b4d143abbfe5c63e4a420056f|Ia28f59a341e1a04b4d143abbfe5c63e4a420056f]], it matched the core logic which also didn't have `returntoquery`, and then VE did not get updated when core was. Easy to fix, I'm not sure how useful it would be though since... > * VE adds target=_blank to the links in the notices, forcing them to open in a new window. This is an understandable choice, even though in theory the editor would recover the contents if you navigate away and then return, but that still seems disruptive. But then, returning to the same page in the new window seems more confusing than useful. Opening the editor in the new window would be even more so. Typically, if you log in in a popup, that popup should close when you are finished. > * The VE UX stays logged out if you log in in a separate window, and still shows the `anoneditwarning` warning, even though the edit will not actually be anonymous if you save it. (This comes with all kinds if side issues, e.g. the save options are different for an anonymous and a logged-in user, such as the "minor" flag or the watchlist options not being available for anons.) This is obviously bad but not easy to fix - the old wikitext editor can be refreshed by doing a preview, but I don't think VE has anything similar. > > Maybe what could be done is: > * make `returnto` point to something like Special:FinishLogin when the link opens in a new window; > * make Special:FinishLogin close the current window; > * before doing that, have it call back to the parent window and trigger an autologin attemept, which will at least refresh the user menu on CentralAuth wikis, although it won't do anything useful in vanilla MediaWiki. > * As a stretch goal, maybe add target=_blank to the wikitext editor as well, and have the JS callback do a preview in that case. **Acceptance Criteria** # Should be able to .... # .... #### Completion checklist **Functionality** [] The patches have been code reviewed and merged [] The task passes its acceptance criteria **Engineering** [] There are existing and passing unit/integration tests [] Tests for every involved patch should pass [] Coverage for every involved project should have improved or stayed the same **Design & QA** [] If the task is UX/Design related: it must be reviewed and approved by the UX/Design team [] Must be reviewed and approved by Quality Assurance. **Documentation** [] Related and updated documentation done where necessary - Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc) - Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments | Extension:GrowthExperiments ]] or [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation | Extension:GrowthExperiments/Technical documentation ]] pages.

**Description** What currently happens: 1.# Logged-out user is editing article in VE on desktop, clicks "Create account" prompt from VE # That opens a new tab; Logged-out user is editing article in VE on desktopfills out account creation form, clicks "Create account" prompt from VEand then is prompted to go to WelcomeSurvey. 1. That opens a new tab; user fills out account creation form, and# WelcomeSurvey offers to take user back to then is prompted to go to WelcomeSurvey. article they were editing 1.Tab 1 has the article with any unsaved changes the user may have already made; WelcomeSurvey offers to take user back toTab 2 has the article they were editingin View mode. Tab 1 has the article with any unsaved changScenario 1: If the user goes the user may have already made;o Tab 1 and presses save, Tab 2 hasVE will tell the article in View mode.m that they're now logged-in, If the user goes to Tab 1 andand that their changes will be associated with the logged-in user if they proceed. * If they presses save "Try again", VE will tell them thatthe edit is associated with the new user account created. * If they're now logged-in press "Dismiss", and that their changes will be associated with the logged-in user if they proceed.they return to the confirmation dialog then press "Publish", If they press "Try again"the edit proceeds, the edit isagain associated with the new user. account created. Video of scenario: {F35649585} >>! In T310320#8245693, @Tgr wrote: > To recap the relevant part of the gerrit discussion: > * VE omits the `returntoquery` parameter that the same "log in or register if you don't want your IP address published" (`anoneditwarning`) notice does use in core. This means it won't return to the editor after going through the signup process. Since we are triggering welcome survey skipping based on whether the user is going to return to editing, the survey won't be skipped. This might be an oversight on VE's part; when the logic was added in [[https://gerrit.wikimedia.org/r/q/Ia28f59a341e1a04b4d143abbfe5c63e4a420056f|Ia28f59a341e1a04b4d143abbfe5c63e4a420056f]], it matched the core logic which also didn't have `returntoquery`, and then VE did not get updated when core was. Easy to fix, I'm not sure how useful it would be though since... > * VE adds target=_blank to the links in the notices, forcing them to open in a new window. This is an understandable choice, even though in theory the editor would recover the contents if you navigate away and then return, but that still seems disruptive. But then, returning to the same page in the new window seems more confusing than useful. Opening the editor in the new window would be even more so. Typically, if you log in in a popup, that popup should close when you are finished. > * The VE UX stays logged out if you log in in a separate window, and still shows the `anoneditwarning` warning, even though the edit will not actually be anonymous if you save it. (This comes with all kinds if side issues, e.g. the save options are different for an anonymous and a logged-in user, such as the "minor" flag or the watchlist options not being available for anons.) This is obviously bad but not easy to fix - the old wikitext editor can be refreshed by doing a preview, but I don't think VE has anything similar. > > Maybe what could be done is: > * make `returnto` point to something like Special:FinishLogin when the link opens in a new window; > * make Special:FinishLogin close the current window; > * before doing that, have it call back to the parent window and trigger an autologin attemept, which will at least refresh the user menu on CentralAuth wikis, although it won't do anything useful in vanilla MediaWiki. > * As a stretch goal, maybe add target=_blank to the wikitext editor as well, and have the JS callback do a preview in that case. **Acceptance Criteria** # Should be able to .... # .... #### Completion checklist **Functionality** [] The patches have been code reviewed and merged [] The task passes its acceptance criteria **Engineering** [] There are existing and passing unit/integration tests [] Tests for every involved patch should pass [] Coverage for every involved project should have improved or stayed the same **Design & QA** [] If the task is UX/Design related: it must be reviewed and approved by the UX/Design team [] Must be reviewed and approved by Quality Assurance. **Documentation** [] Related and updated documentation done where necessary - Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc) - Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments | Extension:GrowthExperiments ]] or [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation | Extension:GrowthExperiments/Technical documentation ]] pages.