Regression: Editor hash fragment behaviour results in editor staying open
Closed, ResolvedPublic1 Estimated Story Points
Actions

Description

reported by user: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?oldid=773859991#Can.27t_back_out_on_mobile

Steps to recreate:

Go to Wikipedia main page in mobile site
Click link to any page on it
Edit that page in mobile Wikipedia and save.
Select back button

User expectation:
Clicking back takes you to Wikipedia main page

Actual:
Clicking back takes you to editor

~~Reported on a Samsung Galaxy S4~~

In addition to this a conflicting request:
After saving an edit in mobile, previously you would be sent to the section of the article that you were editing. This is good and convenient (though sometimes the way it loads means you end up with another section in the viewport, but that's a browser issue). Recently though it's been redirecting to the editor opening at that section, and the back button and the "cancel edit" button don't work. This is never what I want and makes it a huge pain to find my place again to carry on reading. I've found this happening in both Chrome and Firefox for Android.

... What should be done?

Replication steps

Click edit icon.
Click top left icon
Expected: Hash fragment resets
Actual: Hash fragment remains as #/editor/0

Details

	Subject	Repo	Branch	Lines +/-
	Close edit overlay properly on save to retain sensible back button behaviour	mediawiki/extensions/MobileFrontend	master	+4 -1

Customize query in gerrit

Related Objects

Mentioned In: T162237: Back button doesn't work reliably to leave VE
T161400: After saving an edit on mobile view, browser returns to edit screen.
Mentioned Here: T164916: Mobile: Redirect to editor after saving edit

Event Timeline

ovasileva created this task.Apr 4 2017, 10:47 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 4 2017, 10:47 AM

I've updated the ticket based on the discussion. This is actually the expected behaviour. I'm not sure if we want to revisit this, but we could make it operate more like the search.

Per above.

Jdlrobson renamed this task from Back button on mobile failing after edit to Back button on mobile takes users to editor.Apr 4 2017, 10:03 PM

Jdlrobson renamed this task from Back button on mobile takes users to editor to Back button after edit takes user back to editor.

Jdlrobson updated the task description. (Show Details)Apr 4 2017, 10:05 PM

Jdforrester-WMF subscribed.Apr 5 2017, 5:32 PM

This is a product decision. We can do this, but we'd need to talk about whether this is the correct thing to do.

@Jdforrester-WMF - any thoughts on expected behavior here? I think it would make sense to skip the editor and resume the flow prior. Also, do you know what the behavior is for desktop? Currently it seems on desktop:

User edits a page
User selects "back" - page goes to editor
User selects 'back' - page displays as it previously was prior to edit - is this correct?

Sorry, thought I'd replied here but it must have been elsewhere. "Back" from editing should be to the read page (either the current one or if viewing an oldid that one); "back" from the read page having edited should ideally be to the page before they clicked edit.

I.e.:

Step	User action	Back function should take you…
1	View A	noop
2	View B	To 1.
3	Edit B	To 2.
4	View B'	To 1.
5	Edit B'	To 4.
6	View B''	To 1.
7	View old-C	To 6.
8	Edit old-C	To 7.
9	View C'	To 6.

What should happen when a user follows the link http://en.m.wikipedia.org/wiki/Barack_Obama#/editor/0 ?

For background we implemented this back in the mingle days "Story 692: Support for closing overlays with back button" (https://gerrit.wikimedia.org/r/67934). If we can find a URL for that story maybe we can find the rationale. Essentially this means fighting with the hash fragment to ensure completely the editing workflow clears history or dropping permalink support for the editor.

In T162128#3172527, @Jdlrobson wrote:

What should happen when a user follows the link http://en.m.wikipedia.org/wiki/Barack_Obama#/editor/0 ?

From where? If they followed it from https://en.m.wikipedia.org/wiki/Barack_Obama it should return them to that (Step 2). If they URL-hacked it / opened in a new tab, it should be a no-op (step 1).

For background we implemented this back in the mingle days "Story 692: Support for closing overlays with back button" (https://gerrit.wikimedia.org/r/67934). If we can find a URL for that story maybe we can find the rationale. Essentially this means fighting with the hash fragment to ensure completely the editing workflow clears history or dropping permalink support for the editor.

You can copy that from the address bar or copying the link from the edit button, so basically we'd be breaking the ability to share the edit link on mobile web (and arguably breaking the link contract on the web) if we make this a noop. We also rely on the hash link for linking to the editor in various JS dialogs so those would all need to be updated in some way. All possible just a little tricky to untangle the current situation (I'd guess a 5-8 story pointer).

How does VE deal with this? Can you share a link to the visual editor interface using action=veedit?

Jdlrobson merged a task: T164916: Mobile: Redirect to editor after saving edit.May 10 2017, 4:15 PM

Jdlrobson updated the task description. (Show Details)

Jdlrobson added a subscriber: • Elitre.

Jdlrobson renamed this task from Back button after edit takes user back to editor to Revisit and amend browser history behaviour for editing experience.May 10 2017, 4:55 PM

I'm not sure why T164916 was marked as duplicate, but since it was, here's more info on it:

It doesn't seem to reproduce for every section. I've experienced it today with https://en.m.wikipedia.org/wiki/Thirteen_Colonies#Government .

@ovasileva @Jdlrobson I think this task should have higher priority and should be solved sooner than later. Please check following scenario:

Go to https://en.m.wikipedia.org/wiki/Thirteen_Colonies
edit section Education
- Note: Editor will take you to https://en.m.wikipedia.org/wiki/Thirteen_Colonies#/editor/10
hit back button
- Note: You'll see the Article, but the article URL will remain https://en.m.wikipedia.org/wiki/Thirteen_Colonies#/editor/10
hit edit section Religion
- Note: Editor will show Religion section but the URL remains https://en.m.wikipedia.org/wiki/Thirteen_Colonies#/editor/10
now hit back button again
- Note: it doesn't work, you stay on editing

User is stuck, first think what user would do is page refresh. After refresh (because URL is https://en.m.wikipedia.org/wiki/Thirteen_Colonies#/editor/10) user sees editor - editing the Education section. After hitting back he sees editor again with Religion section. There is no way to leave the editor other than editing URL and removing #/editor/10 or opening new wikipedia page.

The editing team is responsible for the editing feature. We'd need to sync with them about any changes here. This is a lot of work and a big architectural revisit. We do not have the bandwidth right now.

@Jdlrobson ok, then we should assign this task to someone else than Olga.

pmiazga added a project: VisualEditor.Jun 28 2017, 11:35 PM

See conversation beginning here: https://phabricator.wikimedia.org/T162128#3169309
Probably needs a real life conversation.

Change 363012 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Close edit overlay on save to retain sensible back button behaviour

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

gerritbot added a project: Patch-For-Review.Jul 3 2017, 3:39 PM

IN the mean time of revamping this.. let's at least make this a little more sensible by removing the back button behaviour after a save ^^^^

phuedx added projects: Readers-Web-Kanbanana-Board-Old, Unplanned-Sprint-Work.Jul 3 2017, 5:16 PM

phuedx moved this task from To Do to Needs Code Review on the Readers-Web-Kanbanana-Board-Old board.

I've managed to trace the bug to https://gerrit.wikimedia.org/r/#/c/338535/ Use OO.ui.confirm for edit abandon message - which was merged by @Jdforrester-WMF and patch by @Esanders . I'm guessing

self.allowCloseWindow.release();

interferes with browser history (which is what Overlay.hide does) and thus the overlay behaviour.

Jdlrobson updated the task description. (Show Details)Jul 3 2017, 5:39 PM

Jdlrobson renamed this task from Revisit and amend browser history behaviour for editing experience to Regression: Editor hash fragment behaviour results in editor staying open.Jul 3 2017, 6:12 PM

Jdlrobson added a project: Regression.

@Jdlrobson - what is the change being made? Should we split this up into two portions the first being closing the editor? Can you update the description so we can give this a priority?

This shouldn't concern the reading team, I'm hoping the editing team will review this patch.

Change 363012 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Close edit overlay properly on save to retain sensible back button behaviour

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

Jdforrester-WMF closed this task as Resolved.Jul 6 2017, 7:14 PM

Jdforrester-WMF reassigned this task from ovasileva to Jdlrobson.

Jdforrester-WMF triaged this task as Medium priority.

Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.

Jdforrester-WMF set the point value for this task to 1.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJul 6 2017, 7:14 PM

ReleaseTaggerBot added a project: MW-1.30-release-notes (WMF-deploy-2017-07-11_(1.30.0-wmf.9)).Jul 8 2017, 4:01 AM

Jdlrobson merged a task: T161400: After saving an edit on mobile view, browser returns to edit screen..Jul 13 2017, 5:49 PM

Jdlrobson mentioned this in T161400: After saving an edit on mobile view, browser returns to edit screen..

Jdlrobson added subscribers: Uziel302, Amire80, IKhitron.

Jdlrobson merged a task: T169172: Edit button on mobile does not work after going back to Read mode .Jul 13 2017, 5:58 PM

Jdlrobson added a subscriber: Ryasmeen.

Jdlrobson merged a task: T164104: Click edit section, click previous page, click previous page. The last click has no effect. The browser is trapped in the page..Jul 19 2017, 1:17 AM

Jdlrobson added a subscriber: Golopotw.

Has this patch been deployed to Wikipedia? I'm still seeing the incorrect behaviour there.

In T162128#3453561, @HairyDude wrote:

Has this patch been deployed to Wikipedia? I'm still seeing the incorrect behaviour there.

I'm seeing the correct behaviour. Here's what I did:

Go to English Wikipedia main page
Click on "Ongoing" to go to Portal:Current events
Add a space somewhere
Click "Save"
Once the page is saved, click the back button

I was taken back the main page, which was what was requested in the task description.

@HairyDude it should be yes. Works for me too. Wmf9 went live on Monday.

• Deskana mentioned this in T162237: Back button doesn't work reliably to leave VE.Oct 13 2017, 12:03 PM

MBinder_WMF moved this task from Product Owner Backlog to 2017-18 Q1 on the Web-Team-Backlog board.Mar 6 2018, 6:52 PM

Regression: Editor hash fragment behaviour results in editor staying openClosed, ResolvedPublic1 Estimated Story PointsActions