@ppelberg and @Esanders will add a description to this task during their 1:1

If we check if either visualeditor-hidebetawelcome or visualeditor-hideusered is set, that should catch almost everyone who has used the editor before. More importantly there should be no false positives.

Change 628409 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/MobileFrontend@master] Only apply desktop preference if we have evidence VE has been used

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

Change 628410 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/MobileFrontend@master] Set MFDefaultEditor to 'preference' by default

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

The first patch (628409) applies the logic of checking the hidebetawelcome/hideusered prefs before using the desktop default, when mobile is configured is 'preference' mode instead of 'source'

If the user hasn't used VE on desktop, we will continue to give them source mode by default (no change).

The second patch (628410) makes 'preference' mode the default, which would make it the default on every wiki. We currently only override this setting on our 'abtest' wikis. Users of the abtest wikis will fall through to the new preference behaviour if they aren't eligible to be in the test.

Task description update
I've added the ===Behavior section to the description.

Next steps

• @Esanders, can you please review the ===Behavior section to ensure 628409 and 628410 implement what is described? Of course, if anything I've included prompts questions, please voice them.

The last-used mobile editor always overrides any desktop preference. This is because we assume that users may want to maintain a different preference on mobile vs desktop.

Anything which has "yes" in "Published an edit on *mobile* before" should therefore say "The editing interface they used to publish their most recent mobile edit".

Also I think the preference is set as soon as you open the editor, so it should actually be "The editing interface they last used on mobile" (and the same for desktop).

The remaining preferences look correct.

In T261423#6495867, @Esanders wrote:

...we assume that users may want to maintain a different preference on mobile vs desktop.

Agreed; I think it's accurate for to continue assuming that people may want to maintain a different preference on mobile vs desktop.

Anything which has "yes" in "Published an edit on *mobile* before" should therefore say "The editing interface they used to publish their most recent mobile edit".

If we were to put the logic you are describing immediately above into effect, wouldn't we be perpetuating the idea that on single-edit-tab wikis, the value people set set in Special:Preferences#mw-prefsection-editing > Editing mode (e.g. Always give me the visual editor if possible) only applies to desktop?

If yes, then I think the name of this setting should be changed so people have a clear idea for what behavior it does and does not affect [i].

Also I think the preference is set as soon as you open the editor, so it should actually be "The editing interface they last used on mobile" (and the same for desktop).

Published an edit on *mobile* before	Published an edit on *desktop* before	Special:Preferences > Editing mode	Interface shown when tapping Edit on mobile
Yes	*	*	The editing interface they last used on mobile

To be clear, you are saying the above to mean the following?

"Last used preferences reflect the editing interface the person last opened, NOT the editing interface the person last used to publish an edit."

i. Note: I'm not suggesting we change the meaning of this setting right now. I think that's out of scope for this task.

To be clear, you are saying the above to mean the following?

I think so, but this is just for our documentation purposes right now, we're not planning on changing anything.

only applies to desktop?
If yes, then I think the name of this setting should be changed

Yes. Although Special:Preferences is not easily accessible on mobile at the moment so it's always been assumed that desktop and mobile preferences are slightly separate. In this case we are just using the desktop preference as a best guess for what a user is expecting the first time they edit on mobile.

In T261423#6500559, @Esanders wrote:

To be clear, you are saying the above to mean the following?

I think so, but this is just for our documentation purposes right now, we're not planning on changing anything.

only applies to desktop?
If yes, then I think the name of this setting should be changed

Yes. Although Special:Preferences is not easily accessible on mobile at the moment so it's always been assumed that desktop and mobile preferences are slightly separate. In this case we are just using the desktop preference as a best guess for what a user is expecting the first time they edit on mobile.

To make sure I'm 100% with you, can you confirm that the following is true?

Were we to implement 628409 and 628410, the tables below would describe how preferences are set/respected.

...once we we have a common understanding on the bolded bit above, I figure we can file additional tickets for changes beyond the scope of this task (e.g. making it explicit values set in Special:Preferences#mw-prefsection-editing > Editing mode are limited to desktop).

TWO EDIT TAB WIKIS

SINGLE-EDIT-TAB-WIKIS [i]

ii. This behavior could change pending the results of the mobile editing interface default A/B test
iii. Currently, the values people set in Special:Preferences#mw-prefsection-editing > Editing mode (e.g. Always give me the visual editor if possible) only apply to desktop. See: T261423#6500559

Were we to implement 628409 and 628410, the tables below would describe how preferences are set/respected.

Looks correct to me.

Once @ppelberg is done reviewing, he will move this back to code review

In T261423#6505150, @Esanders wrote:

Were we to implement 628409 and 628410, the tables below would describe how preferences are set/respected.

Looks correct to me.

Okay, cool. This looks good then.

In T261423#6505934, @JTannerWMF wrote:

Once @ppelberg is done reviewing, he will move this back to code review

Done.

Updated the task description to reflect what was confirmed in T261423#6505150)

Change 628409 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Only apply desktop preference if we have evidence VE has been used

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

Change 628410 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Set MFDefaultEditor to 'preference' by default

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

@ppelberg/ @Esanders: I have recorded all the test results for this on the Reply tool QA workbook:
https://docs.google.com/spreadsheets/d/1ccTSx-v1yb8kvli7e8djFexXL7jThPHE1WomtkCLG6I/edit#gid=975163835

There are some cases that are failing. But there is one issue that is happening consistently for pretty much all cases, which is, the correct editing interface does not show up on mobile until I re-login. It happens specially after a change has been made to the preferences section on desktop or after the user switched the editor on desktop.
You can find those cases marked as Failed with comments on the workbook. Feel free to let me know if I need to clarify something on those cases! :)

The four failures listed as "Failed, opened the editor last used on desktop" I can't reproduce any of these. When I log in on mobile I always get the last editor I used on mobile, regardless of my desktop setting.

the correct editing interface does not show up on mobile until I re-login

I checked the code and the logic for setting your mobile preference currently happens as soon as that editor is loaded, so wherever we say "Published an edit on *mobile* before", it should say "Opened an editor before on *mobile*". That preference is then stored in localStorage, so it's possible by logging out that gets cleared?

We should probably change the mobile editor preference to be a database-stored user preference, rather than using localStorage.

In T261423#6571195, @Esanders wrote:

We should probably change the mobile editor preference to be a database-stored user preference, rather than using localStorage.

Here is a ticket for what you are describing: T266304.

@Esanders: should @Ryasmeen wait until T266304 is resolved to retest the cases she marked as failing [i]?

i. Rows: 10, 15, 16, 17, 18, 24, 25 in the Reply Tool QA

Yes, I think so.

Hey @Ryasmeen , why was this task moved from ready to sign off to blocked?

Because it's not ready to sign off. QA needs to still verify the failed cases after T266304 is fixed.

Patch for T266304 was merged, so maybe this can be tested again now?

In T261423#6635196, @ppelberg wrote:

In T261423#6631404, @matmarex wrote:

Patch for T266304 was merged, so maybe this can be tested again now?

I think so. Accordingly, I'm assigning this back over to @Ryasmeen.

I have re-tested the failing cases, it seems the following ones are still failing.

Rows: 10, 24 and 25.

Check the Reply tool QA spreadsheet for more details:
https://docs.google.com/spreadsheets/d/1ccTSx-v1yb8kvli7e8djFexXL7jThPHE1WomtkCLG6I/edit#gid=975163835

@Ryasmeen Ed left a comment for you in the spreadsheet

In Board Refinement, @Esanders said he would check for failure cases again

@Ryasmeen
For all the failure cases (10/24/25) you state that it uses the previously opened editor for that device which is correct.

On desktop the preference is set when the users opens the editor.
On mobile the preference is set when the user switches editor: T267247

The columns in the spreadsheet indicate you are expecting the preference to only change when the edit is published, which is not the case.

@Esanders: Yeah, I am not sure what I am expecting here is correct. I will try to describe the behavior I am observing for those three scenarios in details here. If you can confirm all the following behaviors are expected, we can close this task :)

Case 10:

Steps:

1. On Desktop, on a TWO EDIT TAB WIKI (Beta cluster) log in with a user who has not Published an edit on *mobile* before neither Published an edit on *desktop* before. (User: Sixteenthuser)

2. Open a page with VisualEditor on desktop

3. Now login to the mobile site on same wiki with the same user.

4. Click on the Edit button.

Expected Result: At this point I expect it will open up the source editor as mentioned under the column "Interface shown when tapping Edit on mobile".

Actual result: It opens up VisualEditor which is the last opened editor on desktop by this user.
Of course, at this point if the user switches the editor on mobile to load the source editor, from that point on it will load the source editor. But it does not work the first time, hence my confusion.

Case 24:

Steps:

1. On mobile, on a SINGLE-EDIT-TAB-WIKIS (en wiki) ) log in with a user who has not Published an edit on *mobile* before but has Published an edit on *desktop* before. (User: Fourteenthuser) and has preference set to "Always give me the visual editor if possible".

2. Open a page with Source Editor on mobile and then close it.

3. Now login to the desktop site on the same wiki with the same user.

4. Click on the Edit button on desktop which will open VisualEditor as expected.

5. Now go back to the mobile site and click on the edit button there.

Expected Result: At this point I expect it will open up VisualEditor as mentioned under the column "Interface shown when tapping Edit on mobile: The editing interface they opened last on desktop".

Actual result: It opens up the source editor which is the last opened editor on mobile by this user.

Case 25:

Steps:

1. On mobile, on a SINGLE-EDIT-TAB-WIKIS (en wiki) ) log in with a user who has not Published an edit on *mobile* before but has Published an edit on *desktop* before. (User: Fourteenthuser) and has preference set to "Always give me the source editor if possible".

2. Open a page with VisualEditor on mobile and then close it.

3. Now login to the desktop site on the same wiki with the same user.

4. Click on the Edit button on desktop which will open the source editor as expected.

5. Now go back to the mobile site and click on the edit button there.

Expected Result: At this point I expect it will open up the source editor as mentioned under the column "Interface shown when tapping Edit on mobile: The editing interface they opened last on desktop".

Actual result: It opens up the VisualEditor which is the last opened editor on mobile by this user.