Decide how we are going to handle editing sections
Open, LowPublic
Actions

Assigned To

None

Authored By

	dom_walden
	Aug 17 2023, 8:12 AM

Description

When to clear edit recovery data

Currently, if you edit a section the edit recovery data is stored in a separate indexeddb record.

You can have multiple records associated with the same page.

For example, if you open the below users and make edits (but don't publish):

you will have three records, one for the entire page and two for the two sections.

However, as soon as you publish an edit (either for the entire page or a section) it will clear all the records associated with the page and you will lose any unsaved edits for the other sections and/or the entire page.

So, for example, if you were now to publish the edits you made to

https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=1

you would lose any edits you made to

How to handle sections added or moved

Sections are identified by a number, for example: title=New_Page_123&action=edit&section=3.

section_numbers_before.png (716×982 px, 77 KB)

These numbers can change if sections are moved around the page or new sections are added above the existing sections. For example, if I make edits to == Section 2 == (but don't publish) https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=3.

In the meantime, if someone adds a section above it like in the screenshot below

section_numbers_after.png (723×989 px, 81 KB)

If I return to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=3 I will be editing a different section (=== Section 1b ===) but it will restore the edit data for the previous section (== Section 2 ==).

Deleted section

If I am editing the last section on the page and someone deletes it, when I go back to edit it you will see "Cannot find section" and therefore you won't be able to recover your edit data.

I would need to edit the entire page to re-add the section or undo the delete (unless you use rollback), but doing that will clear all the recovery data for the page, thus losing their unsaved edit data.

We should decide how we want to handle these cases. Perhaps this is a question for @JSengupta-WMF.

QA Results - Beta

AC	Status	Details
1	❌ https://phabricator.wikimedia.org/T344410 here

Details

	Subject	Repo	Branch	Lines +/-
	Edit Recovery: discard section edit correctly	mediawiki/core	master	+5 -3

Customize query in gerrit

Related Objects

Mentioned In: T352028: Recovery data cleared for whole page when section is saved
T345608: [UX] Design for Edit recovery
Mentioned Here: rMW67f80e68bf55: Merge "Update jsdoc-wmf-theme from 0.0.13 to 1.0.0"
rMWeb82de5b54dc: Merge "Avoid phpunit failures when using --filter=PageUpdaterTest"
T352028: Recovery data cleared for whole page when section is saved

Event Timeline

dom_walden created this task.Aug 17 2023, 8:12 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 17 2023, 8:12 AM

dom_walden updated the task description. (Show Details)Aug 17 2023, 8:13 AM

dom_walden updated the task description. (Show Details)Aug 17 2023, 8:35 AM

dom_walden updated the task description. (Show Details)

MusikAnimal moved this task from New & TBD Tickets to Needs Discussion on the Community-Tech board.Aug 24 2023, 2:06 PM

valerio.bozzolan subscribed.Aug 28 2023, 9:21 AM

Samwilson mentioned this in T345608: [UX] Design for Edit recovery.Sep 7 2023, 1:44 AM

Samwilson moved this task from Backlog to Needs discussion on the Edit Recovery board.Sep 7 2023, 2:06 AM

Change 967756 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] Edit Recovery: discard section edit correctly

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

gerritbot added a project: Patch-For-Review.Oct 23 2023, 6:31 AM

I'm not sure how we want to handle this, but it looks like there's a bug anyway: as things stand, we should be treating sections as their own thing and not deleting them when the whole page or another section is edited.

Maybe we'll change that when we answer the actual question of sections, but it seems best to at least make it consistent for now.

Samwilson claimed this task.Oct 23 2023, 6:37 AM

Samwilson edited projects, added Community-Tech (CommTech-Kanban); removed Community-Tech.

Samwilson moved this task from Ready 🎬 to In Development 💻 on the Community-Tech (CommTech-Kanban) board.

Change 967756 merged by jenkins-bot:

[mediawiki/core@master] Edit Recovery: discard section edit correctly

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

Maintenance_bot removed a project: Patch-For-Review.Oct 23 2023, 10:30 AM

ReleaseTaggerBot added a project: MW-1.42-notes (1.42.0-wmf.2; 2023-10-24).Oct 23 2023, 11:00 AM

@dom_walden Now that sections and the whole page are deleted independently (per the above patch), the behaviour here might be a bit better; can you see what you think?

I'm still not sure if it makes sense to keep sections if the whole page is discarded (or vice versa), and there's still the issue of section numbers being a rather clunky way to track sections, but I'm not sure what should be done.

Samwilson moved this task from Needs discussion to Ready on the Edit Recovery board.Nov 7 2023, 5:55 AM

dom_walden mentioned this in T352028: Recovery data cleared for whole page when section is saved.Nov 27 2023, 2:08 PM

I have raised T352028, but I wonder if we should just move the current bug back into In Development?

Good point, thanks.

Unfortunately, it doesn't seem like there's any way at the moment to determine what section was being edited, in the postEdit hook, so we'll have to add that. It's probably still better to add it there rather than deleting the data on clicking saving because the same might not work.

T352028 has progressed and is now in QA, and the idea is that whole-page vs section editing is handled quite separately and there shouldn't be any interaction between the two (i.e. saving/cancelling the whole page doesn't delete section data, nor vice versa). Whether that's the final state of how we want things to be, but I think it's at least consistent and we can move ahead with it for now. Does that sound okay?

Yes. Let's start with this and see if we get any insights when people start using this feature.

@Samwilson Please see the results below. Firefox seems to be working fine but I had a couple of different issues as seen from Chrome and Safari.

Status: ❌ FAIL
Environment: Beta: 1.42.0-alpha (eb82de5)
OS: macOS Sonoma 14.2.1
Browser: Chrome 120, Firefox 120, Safari 17.2
Skins. Vector 2022
Device: MBA M2
Emulated Device:: n/a
Test Links:
https://en.m.wikipedia.beta.wmflabs.org/wiki/Dog#

❌AC1: https://phabricator.wikimedia.org/T344410

❌Chrome- "Vanilla" was published from https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit but "Vanilla" was not removed from the IndexDB after it was published

Regular	Section 1	Section 2	Publish Changes	Result

❌Safari- "Fish" was published from https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=2 but this time, everything in the IndexedDB is now deleted which includes "Dog" and "Cat"

Regular	Section 1	Section 2	Publish Changes	Result

✅Firefox- "Burger" was publish from https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=2 and the other two still had the previous Edit Recovery words of "Cheese Steak" and "Pork Roll"

Regular	Section 1	Section 2	Publish Changes	Result

GMikesell-WMF updated the task description. (Show Details)Jan 13 2024, 12:23 AM

GMikesell-WMF moved this task from QA 🐛 to Needs Attention 👀 on the Community-Tech (CommTech-Kanban) board.

Samwilson moved this task from Needs Attention 👀 to In Development 💻 on the Community-Tech (CommTech-Kanban) board.Mar 6 2024, 11:44 AM

@GMikesell-WMF It looks like there might've been a few issues here:

We were saving the page text even if it wasn't changed; this is now fixed.
Clearing the page data after saving was ignoring the section number; this is also now fixed.
Lastly, it appears that sometimes browsers' dev tools are showing the contents of the database prior to the last updates, so it's probably best to use Special:EditRecovery or click the 'reload indexedDB' button (although perhaps you were and this is not an issue).

Sorry to have been slow in responding to your test results here. Could you have another look at this and see if things are now working correctly? Thanks!

@GMikesell-WMF mind looking at this once more? We've made a few updates and want to make sure it's working as expected

JWheeler-WMF moved this task from Ready to MVP Scope on the Edit Recovery board.Apr 15 2024, 2:32 PM

@Samwilson @JWheeler-WMF I tested it again and this time Chrome now works but Safari is still having an issue. After a publish in Safari, it was not removed from the IndexDB as seen in the video below.

Status: ❌FAIL
Environment: Beta: 1.43.0-alpha (67f80e6)
OS: macOS Sonoma 14.4.1
Browser: Chrome 123, Safari 17.4.1
Skins. Vector 2022
Device: MBA M2
Emulated Device:: n/a
Test Links:
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=1
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=2

❌AC1: https://phabricator.wikimedia.org/T344410

✅Chrome- "Vanilla" was published from https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit and now "Vanilla" is removed from the IndexDB after it was published

❌Safari- "Blue" was published from https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=2 but this time, everything in the IndexedDB stayed when "Blue" should have been removed since it was published.