@RHo @MMiller_WMF could you please update the "Desired" column in the scenarios that Elena listed above? Thanks!

I just checked all of these. I'm uncertain about this one:

(4) the link inspector is open -> a user clicks on "X", then navigates away, then returns to add link suggested article via browser back button

Could you give an example of what you mean by navigates away? Do you mean clicking on the talk page tab for example? Currently, if the user does that and then uses the browser back function, they'll be in read mode, but clicking edit brings them into machine suggestions mode. Does that sound OK @RHo?

(1) reloads with link inspector open (same behaviour as reloading in VE mode)

That's included in @mewoph's patch in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/685953

In T282290#7081942, @kostajh wrote:

I just checked all of these. I'm uncertain about this one:

(4) the link inspector is open -> a user clicks on "X", then navigates away, then returns to add link suggested article via browser back button

Could you give an example of what you mean by navigates away? Do you mean clicking on the talk page tab for example? Currently, if the user does that and then uses the browser back function, they'll be in read mode, but clicking edit brings them into machine suggestions mode. Does that sound OK @RHo?

Yes, selecting the talk page is one example, or selecting a link in the article to another article was the example I used. I think what you say is happening right now (clicking on edit takes them back to the suggestions editing mode) is correct, so I will adjust my "Desired" comment accordingly. Thanks for checking!

In T282290#7082228, @RHo wrote:

In T282290#7081942, @kostajh wrote:

I just checked all of these. I'm uncertain about this one:

(4) the link inspector is open -> a user clicks on "X", then navigates away, then returns to add link suggested article via browser back button

Could you give an example of what you mean by navigates away? Do you mean clicking on the talk page tab for example? Currently, if the user does that and then uses the browser back function, they'll be in read mode, but clicking edit brings them into machine suggestions mode. Does that sound OK @RHo?

Yes, selecting the talk page is one example, or selecting a link in the article to another article was the example I used. I think what you say is happening right now (clicking on edit takes them back to the suggestions editing mode) is correct, so I will adjust my "Desired" comment accordingly. Thanks for checking!

This is the current behavior. My concern was - should users have an additional guidance (1) when they go away (even there is no interaction with the context items and (2) when they come back to an article with suggested links, should they be inform that Edit should be clicked.

With normal editing workflow, a user should click the Edit button. With the add link, a user is in add link editing mode via clicking on SE article card. To make a connection between Edit button and add link editing mode might be not so obvious. Especially if a user had an experience with opening in editing mode other articles (not suggested link articles).

An ideal example - a user gets to an add link article, does not interact with the context items, clicks 'X' - would see an info message "Click Edit to return to suggested link editing".

In T282290#7082726, @Etonkovidova wrote:

In T282290#7082228, @RHo wrote:

In T282290#7081942, @kostajh wrote:

I just checked all of these. I'm uncertain about this one:

(4) the link inspector is open -> a user clicks on "X", then navigates away, then returns to add link suggested article via browser back button

Could you give an example of what you mean by navigates away? Do you mean clicking on the talk page tab for example? Currently, if the user does that and then uses the browser back function, they'll be in read mode, but clicking edit brings them into machine suggestions mode. Does that sound OK @RHo?

Yes, selecting the talk page is one example, or selecting a link in the article to another article was the example I used. I think what you say is happening right now (clicking on edit takes them back to the suggestions editing mode) is correct, so I will adjust my "Desired" comment accordingly. Thanks for checking!

This is the current behavior. My concern was - should users have an additional guidance (1) when they go away (even there is no interaction with the context items and (2) when they come back to an article with suggested links, should they be inform that Edit should be clicked.

With normal editing workflow, a user should click the Edit button. With the add link, a user is in add link editing mode via clicking on SE article card. To make a connection between Edit button and add link editing mode might be not so obvious. Especially if a user had an experience with opening in editing mode other articles (not suggested link articles).

An ideal example - a user gets to an add link article, does not interact with the context items, clicks 'X' - would see an info message "Click Edit to return to suggested link editing".

Thanks for clarifying, I see what you're saying. My suggestion would be that we revisit this particular scenario when we pick up the work for T269653: Add a link: edit mode toggle (machine suggestions & visual).

The reason the warning shows up when "X" is clicked is that onBeforeExit in MobileFrontEnd is called. For browser back button, the warning is invoked via hashchange event. Unfortunately this assumes that the user enters VE via changing the url hash to #/editor and not directly like we are doing. As an experiment, I tried not setting veaction=edit for add link and opening VE manually — this did lead to a warning w/browser back button.

Some options:

• Alter the history state to include hashes as if the user were to start from read mode
• Bring back the change to open the article via JS click on edit link and handle reload use case
• Detect if the user clicked the back button and invoke the warning via VE's this.getSurface().dialogs.openWindow( 'abandonedit' ) -- this might be tricky since there's no surefire way to detect this, especially on mobile

Change 691253 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: mobile reloading workflows

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

Hi @RHo @kostajh the patch I posted addresses all the above use cases except:

• 1.4 after navigating away I went to the Privacy Policy page), when clicking edit, the user gets regular edit mode rather than machine suggestions. In this case, the suggested edit session is no longer active. This seems consistent with the documentation for suggested edit session. Would it make sense to make this session persist longer?

A suggested edit session starts with a user clicking on a suggested edit task card, and ends with leaving the page associated with the task.

• 2.1 it looks like this browser dialog is only shown on desktop. I tried a regular edit with VE on mobile and this dialog also didn't show up (it did show up when using mobile site on desktop). However, after reloading, the edits were restored. I'm not sure if it's possible for us to show a custom dialog upon reload (mobile browsers ignore dialogs/alerts in onbeforeunload). It might make more sense in this case to make restored edits work. Let me know what you think.

For @RHo review (along with the previous @mewoph comments.

My notes

• 1.1 and 2.1 (reloading a page) does not display the desired behavior - see the @mewoph's note on displaying a warning for this scenario.
• For 1.4 I agree with @mewoph. However, for the most cases of navigating away returning to an add link article and clicking Edit will open the article in Add suggested link mode. Given this, it seems that this scenario does have the desired behavior.

Thanks @Etonkovidova and @mewoph - please see my comments below inline. Happy to resolve this and create two separate tasks for the outstanding items for post-release if you agree:

In T282290#7089539, @Etonkovidova wrote:

For @RHo review (along with the previous @mewoph comments.
My notes

• 1.1 and 2.1 (reloading a page) does not display the desired behavior - see the @mewoph's note on displaying a warning for this scenario.

@mewoph - I was able to get the same reload dialog on mobile when i made an edit and then selected reload using VE on a mobile device - see the updated screenshot in the task description (F34457205 from my Android, Chrome beta browser). However, if it's possible per your comment to restore changes on reload, that would be great. But do you mean this would be in lieu of a warning dialog?

• For 1.4 I agree with @mewoph. However, for the most cases of navigating away returning to an add link article and clicking Edit will open the article in Add suggested link mode. Given this, it seems that this scenario does have the desired behavior.

I agree this is technically in keeping with the session ending (navigating away to privacy policy for example), but might there be a way to provide a timeframe for returning after navigating away to account for accidental/changed-my-mind behaviour? Something like hitting back within 5secs? If that is not easy, then will defer to @MMiller_WMF about letting go of this scenario.

Change 691253 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: mobile reloading workflows

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

@mewoph - I was able to get the same reload dialog on mobile when i made an edit and then selected reload using VE on a mobile device - see the updated screenshot in the task description (F34457205 from my Android, Chrome beta browser). However, if it's possible per your comment to restore changes on reload, that would be great. But do you mean this would be in lieu of a warning dialog?

Hi @RHo, it looks like the lack of reload warning is iOS specific. Here's regular VE edit & reload flow on iOS. My understanding is that some browsers prevent JS from intercepting reloads so it might not be possible to even manually show a dialog (instead of relying on browser warning). In this case, there isn't much we can do except try to save the user's progress like VE does in regular edits.

I agree this is technically in keeping with the session ending (navigating away to privacy policy for example), but might there be a way to provide a timeframe for returning after navigating away to account for accidental/changed-my-mind behaviour? Something like hitting back within 5secs? If that is not easy, then will defer to @MMiller_WMF about letting go of this scenario.

Looking at the code for SuggestedEditSession, it looks like the session is cleared at the beginning of page load (in this case, right when the privacy policy page loads). To accomplish this delay we probably would have to also keep track of when the user leaves the page and/or track the duration of the page visit so that we can determine whether the session should be cleared. To me this seems like a fairly risky change since the same SuggestedEditSession is used for all task types. @kostajh
@Tgr what do you think about adding a "grace period" for suggested edit session?

In T282290#7108131, @mewoph wrote:

I agree this is technically in keeping with the session ending (navigating away to privacy policy for example), but might there be a way to provide a timeframe for returning after navigating away to account for accidental/changed-my-mind behaviour? Something like hitting back within 5secs? If that is not easy, then will defer to @MMiller_WMF about letting go of this scenario.

Looking at the code for SuggestedEditSession, it looks like the session is cleared at the beginning of page load (in this case, right when the privacy policy page loads). To accomplish this delay we probably would have to also keep track of when the user leaves the page and/or track the duration of the page visit so that we can determine whether the session should be cleared. To me this seems like a fairly risky change since the same SuggestedEditSession is used for all task types. @kostajh
@Tgr what do you think about adding a "grace period" for suggested edit session?

My preference would be not to add a grace period here to avoid additional complexity.

1.4 after navigating away I went to the Privacy Policy page), when clicking edit, the user gets regular edit mode rather than machine suggestions. In this case, the suggested edit session is no longer active. This seems consistent with the documentation for suggested edit session. Would it make sense to make this session persist longer?

FWIW on iOS Safari if I click "X", go to the privacy policy page, swipe back, then tap Edit, I'm back in machine suggestions mode.

In T282290#7108131, @mewoph wrote:

Looking at the code for SuggestedEditSession, it looks like the session is cleared at the beginning of page load (in this case, right when the privacy policy page loads). To accomplish this delay we probably would have to also keep track of when the user leaves the page and/or track the duration of the page visit so that we can determine whether the session should be cleared. To me this seems like a fairly risky change since the same SuggestedEditSession is used for all task types. @kostajh @Tgr what do you think about adding a "grace period" for suggested edit session?

Currently at the start of the page load the suggested edit session is either restored (loaded from session storage and set to active) or cleared. This would require a third option, where it's loaded but not active so in case the user is editing some different article, we don't try set up the suggested edits logic; and we'd have to make sure everywhere where we rely on the suggested edit session (which is a lot of places) that it's active. That would take some effort.

The other issue is that it's hard to remember when the user left the page (at the point the browser notifies the client-side logic about it, writing data is already unreliable). We'd have to periodically write some timestamp to localstorage.

So I agree with @kostajh - it's doable, but seems more work than worth it.

FWIW on iOS Safari if I click "X", go to the privacy policy page, swipe back, then tap Edit, I'm back in machine suggestions mode.

If the page is external, the Wikipedia client-side code won't learn about it (the browser's security model is based on domain so the code on one domain can't usually know what's happening on another domain), so that won't affect the session.

Also, terminating the session is something the suggested edits code does when it sees it's on a foreign page. If the code is not loaded at all (it's only loaded in the main and main talk namespace), it won't terminate the session.

And we specifically exempt pages related to the task (like the talk page or history page) so the session is preserved on those as well.

In T282290#7108131, @mewoph wrote:

@mewoph - I was able to get the same reload dialog on mobile when i made an edit and then selected reload using VE on a mobile device - see the updated screenshot in the task description (F34457205 from my Android, Chrome beta browser). However, if it's possible per your comment to restore changes on reload, that would be great. But do you mean this would be in lieu of a warning dialog?

Hi @RHo, it looks like the lack of reload warning is iOS specific. Here's regular VE edit & reload flow on iOS. My understanding is that some browsers prevent JS from intercepting reloads so it might not be possible to even manually show a dialog (instead of relying on browser warning). In this case, there isn't much we can do except try to save the user's progress like VE does in regular edits.

Thanks @mewoph for figuring out the iOS issue. I think that's fine and can clarify in the task that in cases like on iOS where the reload warning dialog does not show, it will just try to load the SE with progress saved and that toast message after reload with the same message as on regular VE reload:

I agree this is technically in keeping with the session ending (navigating away to privacy policy for example), but might there be a way to provide a timeframe for returning after navigating away to account for accidental/changed-my-mind behaviour? Something like hitting back within 5secs? If that is not easy, then will defer to @MMiller_WMF about letting go of this scenario.

Looking at the code for SuggestedEditSession, it looks like the session is cleared at the beginning of page load (in this case, right when the privacy policy page loads). To accomplish this delay we probably would have to also keep track of when the user leaves the page and/or track the duration of the page visit so that we can determine whether the session should be cleared. To me this seems like a fairly risky change since the same SuggestedEditSession is used for all task types. @kostajh @Tgr what do you think about adding a "grace period" for suggested edit session?

In T282290#7110387, @kostajh wrote:

[...]
My preference would be not to add a grace period here to avoid additional complexity.
[...]
FWIW on iOS Safari if I click "X", go to the privacy policy page, swipe back, then tap Edit, I'm back in machine suggestions mode.

In T282290#7111161, @Tgr wrote:

[...]
Currently at the start of the page load the suggested edit session is either restored (loaded from session storage and set to active) or cleared. This would require a third option, where it's loaded but not active so in case the user is editing some different article, we don't try set up the suggested edits logic; and we'd have to make sure everywhere where we rely on the suggested edit session (which is a lot of places) that it's active. That would take some effort.
The other issue is that it's hard to remember when the user left the page (at the point the browser notifies the client-side logic about it, writing data is already unreliable). We'd have to periodically write some timestamp to localstorage.
So I agree with @kostajh - it's doable, but seems more work than worth it.

FWIW on iOS Safari if I click "X", go to the privacy policy page, swipe back, then tap Edit, I'm back in machine suggestions mode.

If the page is external, the Wikipedia client-side code won't learn about it (the browser's security model is based on domain so the code on one domain can't usually know what's happening on another domain), so that won't affect the session.
Also, terminating the session is something the suggested edits code does when it sees it's on a foreign page. If the code is not loaded at all (it's only loaded in the main and main talk namespace), it won't terminate the session.
And we specifically exempt pages related to the task (like the talk page or history page) so the session is preserved on those as well.

Based on my reading comments, it sounds like the "grace period" idea is not worth it, which is fine. However, it also sounds like pages like "privacy policy" should not count (and currently doesn't count) as ending the session. Is that right?

In T282290#7111389, @RHo wrote:

Based on my reading comments, it sounds like the "grace period" idea is not worth it, which is fine. However, it also sounds like pages like "privacy policy" should not count (and currently doesn't count) as ending the session. Is that right?

As far as I can see, yes, unless you visit another article, you should still be in suggested edit mode when you return.